Re: [Distutils] setuptools test command on Windows

At 09:57 PM 8/18/2005 +0200, Thomas Heller wrote:

"Phillip J. Eby" 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.)