Install tangle

[Richard Laager]

On 01/14/2018 10:09 PM, Hal Murray wrote:
>> 1) Does configure bail if installing the python libs might not work? No. 
> 
>> I think #1 always has to be no. Otherwise, you'll break tons of working
>> setups, including but not limited to package builds. 
> 
> Could you please say more.
> 
> I'm assuming that PYTHONPATH or xxx.pth would fix the problem and bailing at 
> configure time just means you have to fix it pre configure/build, similar to 
> setting things up by installing bison and various xxx-devel packages.

Let's take my Ubuntu system for example.

If I run the default:
./waf configure
that is equivalent to:
./waf configure --prefix=/usr/local

which, on Debian derivatives using, for example, Python 2.7 is
equivalent to:
./waf configure --prefix=/usr/local \
    --pythondir=/usr/local/lib/python2.7/dist-packages \
    --pythonarchdir=/usr/local/lib/python2.7/dist-packages

(Note that site-packages becoming dist-packages is a Debian-ism.)

Assuming this is a newly-installed system,
/usr/local/lib/python2.7/dist-packages does not exist. Since it does not
exist, it does not show up in sys.path.

If you follow through with the ./waf install, it will create
/usr/local/lib/python2.7/ntp and put the ntp module files there.

Since /usr/local/lib/python2.7 then exists, it will show up in sys.path
on subsequent runs of python, and everything will work.

If you make ./waf configure bail, you break me needlessly--and everyone
on Debian derivatives and any other distro that includes /usr/local in
sys.path by default.

Warning is fine, as I can ignore a warning.

Setting PYTHONPATH or creating a .pth file is unnecessary. Why should I
have to do that when it would have worked fine without it?

Also, while setting non-existent directories in PYTHONPATH *does* cause
them to show up in sys.path, setting non-existent directories in a .pth
file does *not* cause them to show up in sys.path.

See also the scenario below.

>> If someone is writing a post-install warning, you might want to omit it (or
>> soften the language) if --destdir is set. 
> 
> I was assuming that destdir is only used to put stuff off to the side during 
> packaging.  The will-it-work check should be concerned with the final 
> destination so a configure time check based on prefix and pythondir seems 
> right to me.
> 
> Is there another use case for destdir?

No, that's the case I have in mind.

Consider the same case as above, but this time, we're doing an
install-time check instead of a configure-time check. To be clear, there
is no --destdir yet. I run ./waf install. It creates
/usr/local/lib/python2.7. Then it runs the "will-it-work check". Since
the directory now exists, the check *passes*. That's why post-install is
better than post-configure.

Let's add --destdir to the mix. I run `./waf install --destdir=tmp`. It
creates ./tmp/usr/local/lib/python2.7. If it runs the "will-it-work
check", that will look at sys.path for /usr/local/lib/python2.7. Since
that directory still does not exist (we created one under ./tmp, not /),
the check fails.

If you're going to suggest looking in $DESTDIR, that's just wrong. Even
if you did, it still wouldn't work, as ./tmp/usr/local/lib/python2.7 is
certainly not in the default sys.path.

The will-it-work check will have a lot of false positives in the
--destdir case. That's why I suggest omitting or softening the warning.

-- 
Richard