[Distutils] "just use debian"
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
>>>> 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
>> - 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"
> But I don't want to change the package name.
> 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
> I have an idea: what about having a "known good set" (KGS) like what
>> Zope has built on its
>> a Known Good Set is a set of python package versions, that are known to
>> 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
> Simplistix - Content Management, Zope & Python Consulting
> - http://www.simplistix.co.uk
> Distutils-SIG maillist - Distutils-SIG at python.org
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG