wiki:Packaging

Version 10 (modified by zooko, at 2007-09-21T13:43:31Z) (diff)

--

Packaging

We want to package Tahoe for people to download and use and we want to use 3rd-party libraries. The following are our current desiderata:

  • For certain deployment targets, we can produce a Tahoe binary package for that platform, ship that package to a user using that platform, they can install that package, and it will work. That is: user doesn't have to manually satisfy any dependencies by building other packages.
    • For Ubuntu "edgy" and "feisty" platforms, as well as Debian "etch", this is accomplished by adding the following clause to /etc/apt/sources.list and then running apt-get install allmydata-tahoe:
deb http://allmydata.org/debian  $DIST  main tahoe
  • this covers all major debian-derived platforms released in the last year.

For libraries that Tahoe uses, we have these desiderata:

  • We use the source code as it is written by upstream. That is: no patching required.
  • Use it as it is packaged by upstream. That is: we prefer to get a copy of the source code of the package as upstream prefers to distribute such source code, rather than by pulling from their revision control tool or so on. (But we strongly prefer source packages to binary.)
  • The user doesn't have to manually resolve any conflicts (this means that we either have to automatically use a 3rd-party library if it is already installed or else we have to automatically force Tahoe to use the copy that it came bundled with).
  • Make it convenient for someone to use other versions of the packages that we use e.g. system-wide packages or newer or alternate versions, etc..
  • Bundle required libraries with the Tahoe distribution so that if someone downloads the distribution, moves to a desert island without a net connection, and then installs, it works.

setuptools

One option is to use a Python packaging tool named setuptools.

Advantages (note that each of these are options provided by setuptools, not requirements imposed by the use of setuptools):

  • management of dependencies (even on platforms that don't have a native package manager); This is the important feature.
  • for hackers who want to use Tahoe, and who like setuptools, this makes using Tahoe convenient and pleasant for them
  • replace "build/configure/package/distribute/test/develop" code written in the Make language with code written in Python; One specific instance of this is ./setup.py test which runs the unit tests

We already have a patch which changes Tahoe to use setuptools, but it doesn't solve the "How to integrate smoothly with platform-specific package managers." part yet.

related tickets

The primary ticket for tracking our progress on this issue:

#82 -- remove the "build" step in the "edit, build, run" cycle

Other related tickets:

#10 -- clean up after yourself when told to "make clean"

#47 -- use pyutil as a separate package and contribute src/allmydata/util/* into pyutil