[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2378: the test-from-egg buildstep has started failing on all builders
Tahoe-LAFS
trac at tahoe-lafs.org
Wed Feb 25 22:33:32 UTC 2015
#2378: the test-from-egg buildstep has started failing on all builders
-------------------------+-------------------------------------------------
Reporter: daira | Owner: daira
Type: defect | Status: assigned
Priority: major | Milestone: 1.10.1
Component: | Version: 1.10.0
packaging | Keywords: buildbot test-from-egg blocks-
Resolution: | release
Launchpad Bug: |
-------------------------+-------------------------------------------------
Comment (by warner):
I was able to reproduce this locally, eventually, with the following
(paraphrased slightly):
1. cd ~/tahoe (contains setuptools.egg, really zetuptoolz)
2. python setup.py bdist_egg -> produces "tahoe.egg"
3. mkdir ~/tmp ~/tmp/egginst
4. cd ~/tmp
5. PYTHONPATH=egginst easy_install -d egginst ~/tahoe/dist/tahoe.egg
6. cd egginst
7. PYTHONPATH=~/tahoe/setuptools.egg:./*.egg python tahoe debug trial
The PYTHONPATH in step 5 is necessary to appease `easy_install`, which is
trying to protect you against writing into a directory that you wouldn't
normally read from. The PYTHONPATH in step 7 does two things: it uses
tahoe's zetuptoolz fork, and it makes the dependencies available.
Step 7 produces the "Missing distribution spec" exception.
The `egginst` directory, as populated by `easy_install`, contains an .egg
for every dependency, an `easy-install.pth` which would add them to the
path (if you included `egginst` on PYTHONPATH), and an executable entry-
point script for everything that produced one (tahoe, flappserver,
flogtool, some zfec ones, etc). It is this `tahoe` entrypoint script that
we execute. On my machine, it contains the following:
{{{
#!/usr/local/opt/python/bin/python2.7
# EASY-INSTALL-ENTRY-SCRIPT: 'allmydata-
tahoe==1.10.0.post272','console_scripts','tahoe'
__requires__ = 'allmydata-tahoe==1.10.0.post272'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('allmydata-tahoe==1.10.0.post272',
'console_scripts', 'tahoe')()
)
}}}
(this matches what I'm seeing on freestorm's buildslave).
If I omit tahoe's zetuptoolz egg from the PYTHONPATH in step 7, the
problem goes away, and the tests run normally.
Note that step 5 is using my system-supplied `easy_install`, which reports
its `--version` as `setuptools 12.1`. I think the problem here is a
mismatch between the version of setuptools (zetuptoolz) that produced the
.egg file in step 2, the version of easy_install that installed the egg
(setuptools-12.1) in step 5, and the version of setuptools (zetuptoolz
again) which provides the `pkg_resources` used for execution in step 7.
Our toolchain takes great pains to work even if you don't have setuptools
installed on your system (perhaps due to my early complaints about not
liking setuptools :-), by providing a setuptools/zetuptoolz .egg in the
source tree, and importing it early in `setup.py`. However, step 5 in the
test-from-egg process depends upon having a system-supplied `easy_install`
script. (Tahoe includes setuptools as an egg, but not easy_install).
Digging into the zetuptoolz `pkg_resources`, it seems that the single-
string `__requires__` in the entrypoint script is, ''sometimes'', being
interpreted as a list, causing it to parse each letter of the string as a
separate requirement string. Most of these ("a", "l", "l", "m", etc) are
ignored, but when it finally gets to "=", the parser throws an exception,
because "=" is supposed to have a package name on the left. However, in
other places within `pkg_resources`, the string is correctly interpreted
as a string.
I've seen other entrypoint scripts that provide a list for `__requires__`,
like the one tahoe's `setup.py build` installs into `support/bin/tahoe`:
{{{
#!/usr/local/opt/python/bin/python2.7
# EASY-INSTALL-ENTRY-SCRIPT: 'allmydata-
tahoe==1.10.0.post272.dev0','console_scripts','tahoe'
# generated by zetuptoolz 0.6c16dev5
__requires__ = ['allmydata-tahoe==1.10.0.post272.dev0',
'setuptools>=0.6c6', 'zfec>=1.1.0', 'simplejson>=1.4',
'zope.interface>=3.6.0,!=3.6.3,!=3.6.4', 'foolscap>=0.6.3',
'pycrypto>=2.1.0,!=2.2,!=2.4', 'mock>=0.8.0', 'pycryptopp>=0.6.0',
'Twisted>=13.0.0', 'Nevow>=0.11.1', 'service-identity',
'characteristic>=14.0.0', 'pyasn1>=0.1.4', 'pyasn1-modules',
'pyOpenSSL>=0.13', 'cryptography', 'cffi>=0.8', 'six>=1.4.1', 'enum34',
'pycparser']
import sys
from pkg_resources import load_entry_point
sys.exit(
load_entry_point('allmydata-tahoe==1.10.0.post272.dev0',
'console_scripts', 'tahoe')()
)
}}}
And if I make `easy_install` use tahoe's zetuptoolz egg, by replacing step
5 with:
5b. PYTHONPATH=~/tahoe/setuptools.egg:egginst easy_install -d egginst
~/tahoe/dist/tahoe.egg
then I get the list-`__requires__` entrypoint script like the one in
`support/bin/tahoe`.
So my hunches are:
* zetuptoolz produces, and requires, a `__requires__` list
* in modern setuptools:
* `pkg_resources` accepts a string or a list
* `easy_install` produces a string
and the mismatch is between the version of easy_install that creates the
entrypoint script, and the version of pkg_resources that gets loaded by
that script.
== Solutions ==
So one solution for this ticket might be to use zetuptoolz for the
`easy_install`, like step 5b. I'm experimenting with this to see if it
would work.
A second would be to fix zetuptoolz to look more like modern setuptools.
But I suspect this test is no longer exercising the kind of functionality
we really care about. Nobody installing a tahoe .egg is going to use 5b:
they'll use `easy_install tahoe.egg`. And they won't include tahoe's
zetuptools in PYTHONPATH when they run tahoe, so they'll get their
pkg_resources from the system setuptools. To be relevant, our test should
match real-world usage.
So a third fix is to remove the non-realistic PYTHONPATH= from step 7. The
`easy-install.pth` in egginstalldir means we could probably use:
7b. PYTHONPATH=~/tmp/egginst python tahoe debug trial
(This reflects reality, since eggs are usually installed into something on
the built-in PYTHONPATH, like /usr/local/lib).
Doing that would make the test dependent upon a system-installed
setuptools, but it was already depending on that for easy_install.
I'm going to try this third option and see if it works.
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2378#comment:6>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list