I think we're actually all in violent agreement at this point. I mainly wanted to ensure we had a sensible path forward for this capability that could be made backwards compatible with pkg_resources without too much difficulty :)
To summarise: * default versions will continue to work as they do now * the next generation installation database spec will define a wheel inspired layout for alternative versions * by analogy with egg/egg-info the likely extension for this format is "dist" * for easy discoverability on existing versions of Python, these will be allowed anywhere on sys.path. A future version of Python may define a dedicated "alt-packages" directory, but that won't happen for Python 3.4. * projects that need the alternative versions will need to do *some* kind of sys.path manipulation to make them available for import. I plan to ensure that the new layout "just works" for at least pkg_resources users (once they update to a sufficiently recent version) * this isn't a pip 1.5 timeline idea, but I'll aim to have the installation database spec updated and a coherent proposal together for pip 1.6 to add a "pip altinstall" command that uses the standard layout and naming scheme. Setting the target directory explicitly is sufficient for experimentation with pip, so a command to make it easy isn't urgent. * until this ready, users that need the capability can continue to use the egg layout. Note that this proposal *does not* attempt to solve the "share distributions between virtual environments" problem. That's far more complex, as it requires a cross-platform solution for both namespace package compatible indirect imports (which Eric Snow and I hope to have ready for 3.4), a "dist-link" equivalent to "egg-link" files (mostly a rebranding of an existing tool, but with added support for partially qualified versions) *and* an unversioned way to advertise the fact that the default metadata lives somewhere else (dist-info-link, perhaps?). It is likely that only the "dist-link" part would work completely on earlier Python versions (although it's possible a metapath hook could make the necessary indirect import features available). Note that symlink farms don't really solve the problem, since you can't readily upgrade the symlinked version due to the version being embedded in the dist-info directory name. It's going to take a while to get all the pieces in place, but I'm hopeful we can get this sorted in the pip 1.6 or 1.7 time frame. Cheers, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
