[Distutils] [pyconuk] "just use debian"

Tarek Ziadé ziade.tarek at gmail.com
Tue Sep 30 17:20:49 CEST 2008


On Tue, Sep 30, 2008 at 4:27 PM, Josselin Mouette <joss at debian.org> 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.
>
> And this is not a problem, but something that is desired.
>
> 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.
>
> Again, when a C library changes its ABI, we do not allow it to keep the
> same name. It's as simple as that.

I see, so there's no deprecation processes for a package  ?

I mean, if you change a public API of your package , you *have* to
change its name ?

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"

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

And the development cycles in a python package are really short
compared to OS systems, in fact
we can have quite a few releases before a package is really stable.

>
>> 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. You
> cannot install things as simple (and as critical) as security updates if
> you allow several versions to be installed together.
>

mmm... unless the version is "part of the name" in a way....

[cut]
>> Interesting.. That would mean you would do version conflict resolution
>> at the OS level,   That makes me think about the previous point: how
>> two applications that use conflicting versions that are not comptabile
>> with each other (you have to choose one of them) can cohabit ?
>
> Two conflicting versions must not use the same module namespace. The
> real, fundamental issue, that generates even more brokenness when you
> accept it and work around it, is here. It is a nightmare for the
> developer (who can't rely on a defined API after "import foo"), a
> nightmare for the distributor (who has to use broken-by-design selection
> methods), and a nightmare for the system administrator (who cannot
> easily track what is installed on the system). Forbid that strictly, and
> you'll see that methods that work today for a Linux distribution (where
> we already forbid it) will work just as nicely for all other
> distribution mechanisms.


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.

Maybe the Python community could maintain a known good set of python
packages at PyPI, with a real work on its integrity, like any
OS-vendor does I believe.

And maybe this KGS could be used by Debian as the reference of package versions.

-> if a package is listed in this KGS, it defines the version, for a
given version of Python

then, application developers in Python could work with this KGS, in their code.
And if they can't get a package added in the official KGS, they will
have to be on their own,
inside their application, and maintain their own modules.


>
> Cheers,
> --
>  .''`.
> : :' :      We are debian.org. Lower your prices, surrender your code.
> `. `'       We will add your hardware and software distinctiveness to
>  `-        our own. Resistance is futile.
>



-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/


More information about the Distutils-SIG mailing list