"make install PREFIX=" fails (install outside of source in custom directory)

[nejucomo]

According to InstallDetails:

The "make install" target is a wrapper around "setup.py install" that uses --single-version-externally-managed to bypass the extra checking that setuptools does. This allows "make install" and "make install PREFIX=/usr/local" to work the same way as traditional unix software (via GNU autoconf, etc).

This entire sequence of commands succeeds:

$ python ./setup.py build
$ python ./setup.py test # 0 unexpected errors
$ mkdir /usr/local/stow/allmydata-tahoe-1.4.1
$ make install PREFIX=/usr/local/stow/allmydata-tahoe-1.4.1/
$ cd /usr/local/stow
$ sudo stow allmydata-tahoe-1.4.1/
# cd ~; which tahoe

The output of which shows /usr/local/bin/tahoe as expected.

Yet some dependency or packaging issue is not configured correctly:

$ tahoe --help
Traceback (most recent call last):
  File "/usr/local/bin/tahoe", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 2562, in <module>
    working_set.require(__requires__)
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 626, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 524, in resolve
    raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: allmydata-tahoe==1.4.1

This ticket is satisfied when this use case succeeds and the AdvancedInstall documentation specifies the proper procedure.

[zooko]

Would it be fair to close the ticket after removing the make install target from Makefile​ and the InstallDetails documentation? I don't currently use it, and there are no automated tests for it, so even if we did fix it we wouldn't know if we subsequently broke it again.

So I guess I would say that one can't close this ticket as "fixed" without also adding automated tests. Also that I have higher personal priorities than fixing this.

However, I am one of the people who knows the most about it (i.e. who is probably most responsible for breaking it!), so I'll try to help. My first question is whether it fails if you omit the python ./setup.py build and python ./setup.py test steps in your recipe above. Those two are asking setuptools to do its "normal" setuptools thing as opposed to the --single-version-externally-managed thing. The "normal" setuptools thing includes producing a script in bin/ which asserts that the right versions of the right Python software distributions can be loaded before running the script. The --single-version-externally-managed behavior doesn't do that. So maybe if you omit those other two steps then it will work, or at least fail in new and interesting ways.

Also I would say that InstallDetails should be edited *immediately* to note that this currently doesn't work, or even to comment it out of InstallDetails entirely. By someone who just now read InstallDetails and tried it...

[zooko]

I hate to remove functionality that someone might want, but I hate even more to leave functionality in which doesn't have tests and is (at least for some users some of the time) broken. So unless someone else jumps in, I'm just going to remove the make install target and associated docs.

[zooko]

Okay, I updated InstallDetails to point out that make install PREFIX=foo is broken. I'm just going to bump this ticket out of the 1.5 Milestone and unassign it from me. :-(

[warner]

updated summary.

I'm the one who originally implemented "make install" and "make install PREFIX=", to behave just like regular GNU tools. (it was important to me that you could use the same "make; make test; make install" sequence that is common in other packages). But I don't actually install software very often, so I didn't notice when this broke. I'm pretty sure it's the result of the setuptoolsification. As Zooko said, he probably knows the most about it, but it's low priority for both of us right now, so it may languish for a while.

I suspect we could rewrite the "make install" target in terms of "setup.py install --single-version-externally-managed".

[zooko]

It already does use setup.py install --single-version-externally-managed: Makefile@3855#L68​. I guess that the earlier build step in Nejucomo's transcript created a bin/tahoe which had been built without the --single-version-externally-managed option and then the final install step (invoked from the make install) didn't rebuilt that executable to be free of the --single-version-externally-managed. We could try specifying another build before the install. I really don't want to change the code without first writing a unit test for it, though.

[davidsarah]

Replying to zooko:

Would it be fair to close the ticket after removing the make install target from Makefile​ and the InstallDetails [now AdvancedInstall] documentation? I don't currently use it, and there are no automated tests for it, so even if we did fix it we wouldn't know if we subsequently broke it again.

+1. I'm not sure we should be encouraging or supporting installation using --single-version-externally-managed. This might be "traditional" behaviour, but it's traditionally broken. (​http://tahoe-lafs.org/source/zetuptoolz/trunk/doc/formats.txt explains the problems.)

If someone really wants to do this, they can run setup.py install --single-version-externally-managed (maybe with the --prefix option) manually.

[zooko]

Okay, I will remove the option since it isn't really supported and is arguably (arguably) a bad idea. But not for v1.7.1.

[daira]

make install was removed by #1717.