The old scheme depended upon the bespoke pseudo-virtualenv scheme that
we cooked up long ago (it copied the entire source tree, bin/tahoe and
support/ and all, into the mac .pkg archive). When we moved to real
virtualenvs, that broke.
This new scheme only installs a populated virtualenv into the archive.
It replaces the entry-point bin/tahoe with a script that behaves a lot
like the old bespoke script: it inserts a relative site-packages/ into
sys.path before importing allmydata.scripts.runner and calling run().
This still depends upon the end-users $PATH having a python that is
compatible with the binary modules we've compiled here, and there are
three potentially-differing Pythons to worry about (homebrew, python.org
installers, and Apple's native /usr/bin/python). We'll have to see if
they tend to differ in ways that cause problems (I think the maintainers
generally try to avoid that). If that's an issue, the next level up is
to use bbfreeze or py2app or something in that category, to ship an
entire python, and not just a bundle of libraries.
As we fix ticket:#1582, we'll move to 'tox' for running tests (which
creates its own virtualenv), so I'd like to see which buildslaves
currently have it installed, and which need to be updated.
It looks like DockerHub's automated builds only have access to the
subtree of the source checkout at+below the Dockerfile. Putting the
Dockerfile in misc/build_helpers/ meant that the build process only had
access to misc/build_helpers/, not the full source tree.
Without stripping the single quotes, the generated pagkage filename
also has the undesired single quotes around the version string.
(eg: tahoe-lafs-'1.10.0.post309'-osx.pkg).
After extracting the contents of the package, this script looks at the
output of 'tahoe --version-and-path' to see if the modules are installed
and invoked from the right path.
Author: Ramakrishnan Muthukrishnan <ram@leastauthority.com>
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
setup.py: stop sometimes-depending upon 'stdeb'
setup.cfg: don't try to alias 'sdist_dsc'
misc/build_helpers/build-deb.py: delete this, it was really old anyways
Closes ticket:2282 (trac).
It turns out that TarFile.addfile() doesn't provide a reasonable default
timestamp, resulting in files dated to 1970 (they're probably wearing
bell-bottoms and listening to disco too). Then, when the bdist_egg command
tries to create a *zip*file with those files, it explodes because zipfiles
cannot handle timestamps before 1980 (it prefers boomboxes and jackets with
straps on the shoulders, thank you very much).
This puts a modern time.time() on the members of the tarfile, allowing future
cryptocoderarchaeologists the opportunity to make fun of fashion trends from
the user's chosen era, rather than an artificially older one.
refs #1342
This is from the darcs patch for #1342, which failed to apply on my darcs
tree, so I'm landing it from git. I'm landing the rename-files part
separately from the modify-those-files part to avoid VC complications.
