On 25 February 2000, firstname.lastname@example.org said:
I have two major continued problems even when I do, "export PYTHONPATH=build/lib:build/platlib".
- When developing in the top-level directory of a distribution, the
current directory still comes first in sys.path, so python still thinks the package source directory (with its __init__.py) is where the package lives.
Yeah, I see the problem -- putting test scripts in a test directory is not a full solution; what about interactive sessions? And while it's good practice to put test scripts in a test directory, I don't want to *force* people to do that.
- Even when executing an example script in a sub-directory, python
gets the idea that the package is in build/lib and doesn't find it's extension submodules. If I copy those over to the build/lib subdirectory they are found.
Oops. This is handled properly on installation, since build/lib and build/platlib are merged at that point. I've been wondering for a while why I decided always to build pure Python modules to build/lib, and extensions to build/platlib. You have discovered a very good reason *not* to do so: it breaks the idea of the build tree as a pseudo-installation for testing purposes.
If I think of good strategies for dealing with these problems, I'll post them. In the meantime, it's back to Makefiles for me. :)
I see a couple of solutions: first, put all modules in either build/lib or build/platlib, i.e. do the merge at build-time rather than install-time. Second, have some sort of "build in-place" option that lets developers, well, build in-place. That is, .py files in the source tree wouldn't be touched (they're already in-place!), and extension modules would be put into the source tree. (I still favour putting compiler turds in build/temp.plat -- anyone foresee problems with that?)
I'm still struggling with the Right Way to install modules, so I won't be able to work on fixing the build stuff right away. Keep bugging me though!