[Distutils] [pyconuk] "just use debian"

Josselin Mouette joss at debian.org
Tue Sep 30 16:27:48 CEST 2008


Le mardi 30 septembre 2008 à 15:49 +0200, Tarek Ziadé a écrit :
> The  "Obsoletes" info could be used maybe. But the main problem I can
> see is that
> in any case several versions of the same module can be needed to build
> one application.

This is indeed a problem, and when it happens, it needs fixing instead
of trying to work with it.

> That is what tools like zc.buildout or virtualenv exists  : they are building
> an isolated environment where they install the packages so a given
> Python application
> can run.
> 
> 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.

> 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.

> From your point of view, how could we solve it at Debian level ? to
> kind of isolate a group
> of packages that fit the needs of one given application ?

I think we need to enforce even more the habit to move unstable and
private-use modules to private directories. It is not viable to add them
to public directories. This is something that is done punctually in some
Debian packages, but it should become mandatory for all cases where
there is no API stability. A tool that eases installation and use of
modules in private directories would certainly encourage developers to
do so and improve the situation in this matter.

> (btw A recent change it Python has allowed us to define per-user site-packages
>      http://mail.python.org/pipermail/python-dev/2008-January/076108.html)

This is definitely a nice improvement for those on multi-user systems
without administrative rights, and for those who wish to install a more
recent version of a specific module. However, I don’t think we should
rely on it as the normal way of installing python modules. And
especially, we should not rely on on-demand download/installation of
modules like setuptools does.

> 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. 

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20080930/411cf95e/attachment.pgp>


More information about the Distutils-SIG mailing list