'sudo make install' doesn't work

[davidsarah]

erpo41 wrote on volunteergrid2-l:

Hi all,

Since my node seems stable, I'm beginning to upload my backups into the grid. Since tahoe is running on a dedicated server in its own user account, I need to make the tahoe executable available to my personal user account on that server. (Previously I had been running tahoe out of /home/volunteergrid2/allmydata-tahoe-1.9.1/bin.)

When I tried to install tahoe, I got the following error messages:

  eric@io:/home/volunteergrid2/allmydata-tahoe-1.9.1$ sudo make install
  python ./setup.py install --single-version-externally-managed
  running update_version
  no version-control data found, leaving _version.py alone
  running install
  error: You must specify --record or --root when building system packages
  make: *** [install] Error 1

This is why I hate building/installing from source on Linux. What do --record and --root do? Does "building system packages" refer to building the executable or a deb/rpm package? Do I actually have to go back and rebuild the tahoe executable with those options? If so, where do I insert those options in the "python setup.py build" command line recommended by quickstart.rst for building the executable? What do those options do and what should I set them to on my system?

The 'install' Makefile target should not be using --single-version-externally-managed.

As a workaround, use 'sudo python ./setup.py install'.

[zooko]

I'd like to remove the "make install" target, so that when a user runs sudo make install they get some nice default error message from make saying that there is no such target. That way I won't have to spend my time supporting it, and nor will other programmers like Brian.

Brian: what do you say? Remove it, let them get an error message from make, then hopefully they'll look around for a "README" or look at the web site, find docs/quickstart.rst, and go from there.

[davidsarah]

I asked:

Does this workaround [sudo python setup.py install] work on your system?

erpo41 replied:

Thanks for the suggestion! That command did install the tahoe executable in /usr/local/bin/tahoe, but when I try to run it I get this:

eric@io:/srv/volunteergrid2$ tahoe
Traceback (most recent call last):
  File "/usr/local/bin/tahoe", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 2655,
in <module>
    working_set.require(__requires__)
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 648, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line 546, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: pycryptopp>=0.5.20

I'm guessing that tahoe depends on a lot of external libraries that weren't installed along with the executable when I ran that command.

That's correct.

As a workaround, I copied the /home/volunteergrid2/allmydata-1.9.1 directory to /home/eric, reset the directory ownership, and symlinked the executable into /home/eric/bin. Now I have tahoe for my user account, which is all I really needed anyway.

[davidsarah]

Replying to zooko:

I'd like to remove the "make install" target, so that when a user runs sudo make install they get some nice default error message from make saying that there is no such target. That way I won't have to spend my time supporting it, and nor will other programmers like Brian.

+1. It appears this user didn't actually want a system install, anyway.

[warner]

Yeah, I'm ok with removing "make install", as long as packagers aren't using it.

The original idea with "make install", which existed long before we started using setuptools, was to make traditional autoconf/unix-style build/install commands work. In that world (my homeland, you might say) "make; sudo make install" is all you need to put things in the right place. And "make install PREFIX=/xyz" was the right way to install it somewhere other than /usr/local, which was convenient for packagers (where /xyz was usually ./temp-pkg-dir and got tarred up and turned into a distribution package).

That PREFIX=/xyz didn't work with "setup.py install" once setuptools came to call, because it insists upon the installation directory already being in your PYTHONPATH, and also installed that weird .pkg-info metadata (at least I considered it weird at the time). So I added those extra flags to the Makefile both to remind myself of what they were, and to allow "make install PREFIX=" to be useful to packagers that wanted the traditional interface.

If our packagers are all using setuptools-native commands (some form of setup.py install that points to a local directory), then we can remove the "make install" target. The current ubuntu packaging (​http://archive.ubuntu.com/ubuntu/pool/universe/t/tahoe-lafs/tahoe-lafs_1.8.3-2.debian.tar.gz) appears to use this:

python setup.py install \
 --no-compile --install-layout=deb \
 --single-version-externally-managed \
 --root $(CURDIR)/debian/$(package)

(i.e. what 'make install PREFIX=' used to do). So they won't be affected. We should check with the other packagers to make sure this won't impact them, but if so, they should really switch to the ubuntu scheme.

[daira]

Pull request at ​https://github.com/tahoe-lafs/tahoe-lafs/pull/44.

[daira]

Fixed in [d85a75d7f689cb55ecddb319dc2057f38e4db87a/trunk].