[Distutils] distribute's sandboxing doesn't preserve working_set; leads to setup_requires problems

[P.J. Eby]

At 04:10 PM 5/19/2011 -0400, Erik Bray wrote:
>Hello all,
>I've got a tricky problem I'm trying to deal with.  Here's the scenario:
>
>I'm trying to build a package that has two requirements in
>setup_requires; let's say `setup_requires = ['package_A',
>'package_B']`.
>The problem is that "package_B" also contains "package_A" in its own
>setup_requires.
>
>What happens when I do an install/build is that package_B is
>downloaded and installed--in the process it also downloads and
>installs package_A in its sandbox.  This wouldn't be a problem except
>that the sandboxed temp install of package_A is left in
>pkg_resources.working_set.entries, and so it's assumed package_A is
>already installed, and the main install doesn't try to fetch it.
>However, when it goes to import from package_A, I get an import error
>(because the sandbox it was installed in has since been deleted).
>
>If I reverse the order it doesn't work either for a different, but
>related problem.  package_A gets installed into the cwd and is added
>to pkg_resources.working_set.  When package_B is installed it uses the
>existing package_A installation, so that's fine.  But then, due to
>some complicated interplay, package_A never gets added to sys.path.
>
>I'd consider this a defect, though I'm wondering if there's something
>I could do differently to avoid this situation.

One such workaround would be to use setuptools, since I fixed this 
bug a couple of years ago.

(Apparently, the fix still hasn't made it to Distribute.)