Robert Collins has an interesting use case, though I'm not sure about his proposed solution. This probably touches on upstream and Debian packaging, so in the spirit of starting a discussion, I forward his pvtmsg here for debate (with his permission). -Barry Begin forwarded message: Date: Fri, 20 Aug 2010 09:22:20 +1200 From: Robert Collins <robert.collins@canonical.com> To: Barry Warsaw <barry@python.org> Subject: Python packaging, dependencies, upstream facilities So, I'm going to give you a use case that debian packages suck at for python (they don't for C) and how I see a path-to-a-solution. If you were to make this happen, it would be oh so lovely. The use case - bare essentials, there are many versions of this. Deploy 2 versions of Launchpad to the same host at the same time, when an incompatible change to a dependency has happened. E.g. zope does a release that moves an attribute; our old version of LP would no longer work, and our new version of LP has other changes that mean it won't work on the old zope. How does this suck? If you upgrade the old zope, the running process is now running without the python files it loaded. Ugh. If you don't upgrade the old zope, you can't run the new LP. Ugh. What we do today, you know: we don't use debian packages for the dependencies. Which means we need a whole parallel dependency structure, tools to manage them, etc etc. Path to a solution: use an API marker analgous to the ABI markers C libraries have. Incompatible changes to a package bump the package *name*. e.g. python-zope.publication2.3 to python-zope.publication2.4 Compatible changes don't: python-zope.publication2.3-2.3.0ubuntu0 to python-zope.publication2.3-2.3.1ubuntu0 Both packages would provide python-zope.publication, but not conflict with each other. Software built on these that needs a specific version of the API would depend on python-zope.publication2.4 or whatever. And a debhelper script, like the C ABI one, could look at what build deps are installed to automate *that*. Problem is, stock python, has no API versioning concept. 'import foo' -> there can only be one. So one needs someline like 'Require(2.3)' or however the black magic setuptools stuff is spelt to be available. Specifically: - python-packageN and python-packageN+Y must be coinstallable - neither can use /site-packages/package - importing just 'package' should get the highest versioned one unless one is already loaded - using Require or something should get the highest versioned one matching your needs unless one is already loaded. Get this working, and the use case becomes: Install both versions of the dependency. Profit -Rob
Attachment:
signature.asc
Description: PGP signature