zooko helped me unravel a build weirdness today. somehow the system installed
twisted (/System/Library) was pulling in parts of the other twisted (/Library)
which had been installed by easy_install, and exploding.
getting rid of the latter helped, but it took this change to get the tahoe
build to stop trying to rebuild twisted and instead use the one that was
already installed. c.f. tkt #229
The 'make build' target now runs 'setup.py build_tahoe', which figures out
where the target 'supportlib' directory should go, and invokes 'setup.py
develop' with the appropriate arguments.
The 'make test' target now runs 'setup.py trial', which manages sys.path and
runs trial as a subroutine instead of spawning an external process. This
simplifies the case where Twisted was built as a dependent library (and thus
the 'trial' executable is not on PATH).
setup.py now manages sys.path and PYTHONPATH for its internal subcommands, so
the $(PP) prefix was removed from all Makefile targets that invoke setup.py .
For the remaining ones, the 'setup.py -q show_pythonpath' subcommand was
added to compute this prefix with python rather than with fragile
shell/Makefile syntax.
Remove docs/install-details.html and README.win32 for now (see #282).
Remove checks for pywin32 and pyopenssl in Makefile -- that is (or will be) automated by setuptools.
Remove twisted from setup_requires. This causes the problem in which Nevow doesn't declare its dependency on Twisted (#440) to yield a clear ImportError mentioning Twisted and to fail repeatedly, rather than yielding a weird ImportError and working on the second identical attempt.
Fix Makefile to set PATH so that trial and twistd can be found by "make test" after Twisted was installed into support/ during "make"
Using pkg_resources.require() like this also apparently allows people to install multiple different versions of packages on their system and tahoe (if pkg_resources is available to it) will import the version of the package that it requires. I haven't tested this feature.
Now we use "./setup.py develop" to ensure that changes to our source code are immediately used without requiring a "make" step. This simplification will hopefully pave the way for easier py2exe and py2app, solving the "Unit tests test the installed version" bug (#145), and perhaps also #164 and #176.
This patch also conditionalizes the use of setuptools_darcs on the absence of a PKG-INFO file, which is part of fixing #263.
Technically, we could get away with v0.6c5 or v0.6c4 on non-cygwin platforms, but if someone currently doesn't have setuptools >= v0.6c6 installed then our setup process will just use our bundled setuptools v0.6c7 anyway, so it will still work, and this makes the setup.py and the accompanying documentation simpler.
Unfortunately, there is no way to claim that we are under a Free Software/Open
Source licence without also claiming to be under a licence that we are not or
claiming to have approval from DFSG or OSI, which we haven't.
Until now, I erred on the side of choosing the licence that is closest to our
from the list (GPL), but that was a bad idea and now I'm erring on the side of
not including a machine-readable licensing claim at all.
Hopefully humans who are interested will quickly find out that we are actually
under a Real Free Software Licence.
But really, this underscores that we need to talk to FSF, edit our licence for
clarity of intent, and submit it to DFSG/OSI.
This means that by default the allmydata-tahoe egg will be a directory with a tree of files instead of a zip file containing files. I prefer the former because it makes it easier for people to hack into it.
Unfortunately the files therein are still going to be .pyc's instead of .py's, if I understand correctly. I would prefer for them to be .py's. See also discussion on the distutils-sig mailing list:
http://mail.python.org/pipermail/distutils-sig/2007-July/007827.html
Now the instructions about how to download debian packages live on a separate
page of the wiki instead of on the front page or in the README. The README is
only about building from source. The front page contains pointers to those two
other pages (the debiandownloadpage and the README).
Note that using "whatever version of python the name 'python' maps to in the current shell environment" is more error-prone that specifying which python you mean, such as by executing "/usr/bin/python setup.py" instead of executing "./setup.py". When you build tahoe (by running "make") it will make a copy of bin/allmydata-tahoe in instdir/bin/allmydata-tahoe with the shebang line rewritten to execute the specific version of python that was used when building instead of to execute "/usr/bin/env python".
However, it seems better that the default for lazy people be "whatever 'python' means currently" instead of "whatever 'python' meant to the manufacturer of your operating system".
Zooko O'Whielacronx