At 10:13 AM 3/16/2006 -0600, Ian Bicking wrote:
It occurs to me that maybe it would be easiest to create an RPM that includes Paste, PasteDeploy, and PasteScript all together? That would simplify all of this, it seems.
That would certainly fix the conflict problem in the short term. In the long run, I'd like a better solution, though. Separate components for namespace packages are too good a thing to give up on without a fight. I'm tempted to see if there isn't a way to create an import hook in pkg_resources that would allow namespace packages to work without having an __init__.py. That would eliminate the file conflicts, albeit at the expense of requiring pkg_resources to be imported before any namespace packages. That seems problematic, though, since it would only be needed for --svem pacakges. The fundamental problem is that you end up having to have dummy packages to hold the __init__.py, or else you have to have something that gets imported first. It seems a bit fragile. One hack would be to add a .pth file for each --svem install of a namespace package, something like "PasteDeploy-nspkg.pth", that contains some code to activate the namespace package, like: import sys,new; \ m = sys.modules.setdefault('paste',new.module('paste')); \ p = os.path.join(sys._getframe(1).f_locals['sitedir'], 'paste'); \ mp = m.__path__ = getattr(m,'__path__',[]); \ (p not in mp) and mp.append(p) Yeah, that would do the trick, if --svem installs left out the __init__.py for declared namespace packages. Of course, this slows down Python startup time when you have a lot of --svem namespace packages installed, and doesn't work with "python -S", but what else can we do? If a given system packager wants to handle namespace packages differently, we could probably accomodate that via modifiers to the --svem mode. Really, the hardest part of implementing this is going to be the bits of setuptools that need to munge the build_py and install_lib commands to leave out __init__ files for namespace packages. I'll probably also need to document how to deal with certain legacy situations where there is an official package that "owns" the namespace and needs to install an __init__.py that actually contains code.