Opened at 2009-03-09T16:47:40Z
Closed at 2016-03-26T23:21:55Z
#657 closed defect (fixed)
"python ./setup.py test" rebuilds packages
Reported by: | zooko | Owned by: | zooko |
---|---|---|---|
Priority: | minor | Milestone: | 1.11.0 |
Component: | packaging | Version: | 1.3.0 |
Keywords: | setuptools | Cc: | |
Launchpad Bug: |
Description (last modified by warner)
If you build with python ./setup.py build, it will automatically build required libraries such as pycryptopp. On Zandr's NAS device, building pycryptopp takes about an hour. Then if you test with python ./setup.py test, it will rebuild pycryptopp *again*. I investigated and I see that this is because the initial build puts the resulting package into ./support/lib/python2.5/site-packages, but the test puts it into the current working directory. So a good fix would be to configure it so that the test step uses ./support/ as its "target directory".
You can work-around this issue by installing with python ./setup.py install, which will copy all libraries such as pycryptopp into your system directory (e.g. /usr/lib/python2.5/site-packages, or by manually prepending the test step with PYTHONPATH=./support/lib/python2.5/site-packages.
(Note that if you install with python ./setup.py install then it is *very easy to uninstall*. All you do is /bin/rm -rf the *one* item that got added into your /usr/lib/python2.5/site-packages/ directory for each library that got installed. For example, for pycryptopp that item is named pycryptopp-$VERSION_NUMBER-py2.5.egg.)
Change History (8)
comment:1 Changed at 2009-03-09T16:50:47Z by zooko
comment:2 Changed at 2009-03-09T16:50:58Z by zooko
- Component changed from unknown to packaging
- Owner changed from nobody to somebody
comment:3 Changed at 2009-03-09T21:14:10Z by warner
ah, this matches what I was experiencing on OS-X last week.
I guess I'm not surprised that the setuptools 'test' target is doing a compile (I can see it helping people who forget/decline to do a 'build' first, and I can imagine the setuptools folks believing that their is-a-library-already-installed logic working fast enough and correctly enough to avoid repeating a lot of work on each test pass). What I am surprised about is that it appears to compile+copy things into the working directory (which I assume is the root of the source tree). I would expect it to compile+copy things into build/lib, and then add that directory to PYTHONPATH before running the tests. Isn't that what build/ is for?
Thanks for the note about how easy it is to manually uninstall things that you've allowed setuptools to write to system directories.. that makes me feel like I have more control over my system if I had to resort to 'sudo setup.py install'.
comment:4 Changed at 2009-08-06T18:30:56Z by zooko
This may be related to #717 (unnecessary rebuild of dependencies when tahoe-deps/ is present).
comment:5 Changed at 2009-10-14T15:09:25Z by zooko
- Owner changed from somebody to cgalvan
It looks like this may be related to http://bugs.python.org/setuptools/issue65 (setuptools bug,inconsistent replacement of eggs when installing from file:// urls.) which is fixed in setuptools-0.6c10 prerelease. setuptools 65 is related to http://bugs.python.org/setuptools/issue17 (easy_install will install a package that is already there) and http://bugs.python.org/setuptools/issue20 (package required at build time seems to be not fully present at install time?).
Maybe someone (cgalvan?) could test this issue with the setuptools v0.6c10.
comment:6 Changed at 2010-04-28T20:42:13Z by zooko
- Keywords setuptools added
- Milestone changed from eventually to 1.7.0
- Owner changed from cgalvan to zooko
- Status changed from new to assigned
comment:7 Changed at 2010-06-16T04:41:03Z by zooko
- Milestone changed from 1.7.0 to eventually
comment:8 Changed at 2016-03-26T23:21:55Z by warner
- Description modified (diff)
- Milestone changed from eventually to 1.11.0
- Resolution set to fixed
- Status changed from assigned to closed
We've removed the setup.py test command (which was an alias for "build a bunch of stuff and then run trial"). And we've switched to tox for running unit tests, where our tox.ini just runs trial in its virtualenv.
So I think we can close this out now.
I added a ticket for setuptools_trial for a way that it could help with this: http://allmydata.org/trac/setuptools_trial/ticket/6 # accept a --prefix option for where to put install requirements (or to find them)