[Catalog-sig] [Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals
david at ar.media.kyoto-u.ac.jp
Wed Oct 8 04:58:20 CEST 2008
Tarek Ziadé wrote:
> On Sun, Oct 5, 2008 at 12:04 PM, zooko <zooko at zooko.com> wrote:
>>> 5/ ideally, they should be one and only one version of a given package
>>> in an OS-based installation
>> -1 -- This is the strong preference of the folks who package software for
>> OSes -- Debian, Fedora, etc. -- but it is not necessarily the choice of the
>> users who use their OSes. It is best for the Python packaging standards to
>> be agnostic towards this, or at least to support both this desideratum and
>> its opposite.
It is not just a strong preference of the Linux guys, it is proper
software engineering. It is fine for developers to have several versions
installed at the same time, but we should really discourage developers
to depend on the possibility to deploy several versions of the same
package, at least in the site-packages owned by the system.
The problem is not just for linux guys: by enabling everyone to deploy
several versions, you encourage people not to care about API
compatibility, and then quikcly, in the dependencies, you will have
depends on foo >= 1.2 (foo < 1.3), which quickly means it will fail
because a package A depends on B and C, and B depends on foo 1.2 and C
1.3. By encouraging multiple versions, you are encouraging this kind of
failures all the time.
If people want to try several versions, there is virtual env and co (or
just installing several python interpreters). It should be a *developer
only* convenience as much as possible. We can have a system to control
imported versions, but without support from python interpreter, it will
be unreliable, and keeps breaking as it does now.
More information about the Catalog-SIG