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.
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
