[Distutils] setuptools test command on Windows

[Phillip J. Eby]

At 09:57 PM 8/18/2005 +0200, Thomas Heller wrote:
>"Phillip J. Eby" <pje at telecommunity.com> writes:
> > At 07:08 PM 8/18/2005 +0200, Thomas Heller wrote:
> >>Is there anything in setuptools to work around that problem, or are
> >>there any plans or ideas how this could work?
> >
> > Well, it occurs to me that it would be good for setuptools to track the
> > last-built platform and Python version, and use "build_ext -if" if it
> > differs from the current platform.  That wouldn't allow simultaneous 
> use of
> > different platforms in the same directory, but it would allow serial
> > switching between Python versions or platforms (e.g. even cygwin vs. 
> win32)
> > to be relatively painless.
>
>build_ext -f rebuilds everything, which takes a long time for ctypes, at
>least - because it reconfigures and rebuilds libffi also.
>Since all the object files are still there, and in separate build
>directories, deleting only the extensions would be enough.

That might be doable.


>Anyway, I was more thinking of a Python loader module in the current
>directory, which would determine the platform-specific lib-directory,
>and use imp to load the extension from there, and then update it's
>globals from the extension.  But I cannot currently figure out how to do
>that in a robust way.

bdist_egg already creates stubs that do this for loading extensions from 
zip files.  The problem is that it has to generate .py files of the same 
name.  Putting them into the user's source tree seems wrong, however.

Maybe a better solution would be to always build in the normal build 
directories, and then have "test" and "develop" just copy or symlink the 
extensions from the build directories to the source directories.  Thus they 
would just run "build_ext" normally (without -i or -f), followed by some 
copying or linking operations.

I can see that you'd like to support simultaneous use of the same source 
tree from different Pythons, but the only way I can see to make that work 
is to put a stub loader directly.  Your solution isn't viable for "develop" 
however, aside from the fact that it doesn't support extensions in 
packages.  (Packages installed using "develop" don't necessarily have the 
setup directory on their path.)

I do have an idea as to how it could still be accomplished, but it's 
terribly complex and would add a lot of extra code to pkg_resources, and it 
wouldn't allow you to "develop" packages containing extensions without 
importing pkg_resources.  Really, putting the stub loader in the source 
tree is the only I can think of that would work in all cases.  But it's 
also really ugly because it will need to know the build base directory 
(which might not be "build", after all), and because it runs the risk of 
ending up in somebody's sdist, CVS or SVN tree.  There's also the 
complication of needing to overwrite it with a different stub loader during 
bdist_egg.

So, my current inclination is to build_ext in the build directory and then 
copy or symlink the extensions, since it leaves the source and bdist trees 
clean and should work with "develop" out of the box, as long as you rerun 
"develop" whenever you switch Pythons.  (It won't be an issue for the 
"test" command, as long as you don't simultaneously run tests with 
different Pythons.)