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.
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
