[Distutils] "just use debian"

Tarek Ziade tarek.ziade at ingeniweb.com
Tue Sep 30 17:51:38 CEST 2008

2008/9/30 Chris Withers <chris at 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
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

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 : / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une société du groupe Alter Way
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080930/18abc4c9/attachment-0001.htm>

More information about the Distutils-SIG mailing list