The bug tracker for setuptools 0.7 or higher is on BitBucket



Author zooko
Recipients cgalvan, pje, zooko
Date 2009-02-04.18:54:14
Hm, I have a new problem which is intimately related to this patch.  The problem
is that package A setup_requires packages B and C, and package B setup_requires
package D, and package C also setup_requires package D.

All four packages are available as sdists.

I get an import error from C's attempt to use D when C is being built.

A lot of investigation in setuptools and pkg_resources suggests to me that what
is happening is that D is added to the pkg_resources working set during the
build of B, and then D's entry in sys.modules is removed by the sandboxing
mechanism described in this ticket (I'm using that patch), and then when C is
built it sees D in the working set so it doesn't attempt to rebuild or active
it, but when it tries to import it, it gets an import error.

Also, by the way, D is installed in .egg form into a temporary directory which
is being used to build B, and that directory is destroyed after B is built, so
by the time C is being built the D.egg is no longer available on the filesystem.

My current thinking is that sandboxing by subprocess would solve this particular
issue as well as being more robust again unanticipated side-effects like this in
general, so I'd like to try a patch that does that.

However, right now, I am instead going to modify by B and C tools so that they
do not require my D tool.

For reference, A == tahoe, B == setuptools_darcs, C == setuptools_trial, and D
== darcsver.
Date User Action Args
2009-02-04 18:54:14zookosetmessageid: <>
2009-02-04 18:54:14zookosetrecipients: + zooko, cgalvan, pje
2009-02-04 18:54:14zookolinkissue20 messages
2009-02-04 18:54:14zookocreate