2008/9/30 Chris Withers <chris@simplistix.co.uk>
Tarek Ziadé wrote:
In other words the problem we have today with an OS-based installation is that
you cannot really have two versions of the same package installed,
that would make happy
two Python applications.

Right, which is why dependencies can often be best matched by a project-based tool like buildout rather than having to have one python setup support all use cases.


No, the problem we have today is that some developers are providing
modules without API stability, which means you cannot simply depend on a
module, you need a specific version.

This problem is never going away, it's the nature of software.


Again, when a C library changes its ABI, we do not allow it to keep the
same name. It's as simple as that.

That's insane, and I bet without trying to hard, I could find examples of violation of this supposed practice.


My convention is to :
 - keep the the old API and the new API in the new version, let's say "2.0"
 - mark the old API as deprecated (we have this "warning'" module in
Python to do so)
 - remove the old API in the next release, like "2.1"

Right.


But I don't want to change the package name.

Right.


The setuptools project has partly improved this by providing a way to
install several
version of the same package in Python and give a way to select which
one is active.
This is not an improvement, it is a nightmare for the sysadmin.

Absolutely. This multi-version rubbish is totally and utterly insanely wrong.


I have an idea: what about having a "known good set" (KGS) like what
Zope has built on its
side.

a Known Good Set is a set of python package versions, that are known to provide
the good execution context for a given version of Python.

Given how poorly maintained Zope's "KGS" is, I think this is a pipe dream.

Besides, accurately specified dependency information, including versions, within a package should suffice. It would be handy if you could also specify python version compatibility in this, something that setuptools does not currently support AFAIK.

you can use the Requires-Python metadata though.

For KGS I agree that this is a big work, but there's the need to work at a higher level that in your package

that is what zc.buildout brought in a way,  but at the application level, and with no respect to the OS-level in a way.
 Si we should find a way to generalize this at Python level imho: being able to develop your package in a known environment.
and being able to give that info to the OS.

Python frameworks are exploding in a myriad of packags : a Python instalation needs to  handle up to a hundreds of public packages now to run a plone site for example




cheers,


Chris

--
Simplistix - Content Management, Zope & Python Consulting
          - http://www.simplistix.co.uk
_______________________________________________



--
Tarek Ziadé - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - Bâtiment D - 9ème étage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une société du groupe Alter Way