On Tue, Sep 30, 2008 at 4:27 PM, Josselin Mouette <[EMAIL PROTECTED]> 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/ _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
