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. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
