[Distutils] default installs and plugins

[Phillip J. Eby]

At 11:30 AM 12/21/2005 -0600, Ian Bicking wrote:
>I'm still finding it impossible to use multiple versions of a package
>unless none of them show up in a .pth file (i.e., none are available
>without requiring), I get a VersionConflict.  I think this may be
>because I iterate over entry points early on, then do a require later.

No, it's because the initial working set is fixed once pkg_resources is 
imported.  I'm contemplating ways to make the working set more fluid in 
0.7, so that which version of something you're using can change until 
you've imported it, searched for it, or require()d it.  Right now, though, 
anything that's the default version gets locked in as the available version 
as soon as pkg_resources is imported.  The only way around it is to have a 
__requires__ specified in __main__, which is what easy_install-generated 
wrapper scripts do.  So, if a particular package version is explicitly 
required by a script, then it can override the default version.  But 
currently that is the *only* way to override a default version and it has 
to be done from __main__ *before* pkg_resources is imported.

I definitely want to change this in 0.7, but am waiting until then because 
it's a potentially destabilizing change and I want a stable (ha!) 0.6a9 or 
a10 out there for people to use while 0.7a1 is in development.


>Conversely, if I don't have a default version installed, I don't see any
>entry points while iterating until the package is required.  I can kind
>of resolve this by adding a --require option to any command that uses
>plugins, but this feels like I'm going down the path of CLASSPATH-like
>command invocation.
>
>I'm not even sure what the resolution would or can be, except that it
>means that I don't see any way to reasonably use versioning and plugins
>together.

That's only possible/practical in the case where you have a specific 
directory for plugins; i.e. a pluggable application with possibly multiple 
instances.  For example, Zope and Trac do this, although I don't believe 
either has specific support for multiple versions.

In situations using more global tools, it's necessary to have plugins be 
global, which in turn implies a particular version of the plugin.


>   This worries me, since I have lots of code that is both
>package and plugin, and if this is the situation then I'll have to move
>to non-root installs everywhere I want version isolation.  (Which I
>actually suspect I'll have to do anyway, but I was hoping that things
>would at least be usable without it).

There are a number other custom installation strategies available besides 
the "virtual python" one, now.  You might check those out on the 
EasyInstall page.