2008/9/30 Chris Withers <[EMAIL PROTECTED]> > Tarek Ziadé 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. >>>> >>> > Right, which is why dependencies can often be best matched by a > project-based tool like buildout rather than having to have one python setup > support all use cases. > > 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. >>> >> > This problem is never going away, it's the nature of software. > > Again, when a C library changes its ABI, we do not allow it to keep the >>> same name. It's as simple as that. >>> >> > That's insane, and I bet without trying to hard, I could find examples of > violation of this supposed practice. > > 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" >> > > Right. > > But I don't want to change the package name. >> > > Right. > > 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. >>> >> > Absolutely. This multi-version rubbish is totally and utterly insanely > wrong. > > 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. >> > > Given how poorly maintained Zope's "KGS" is, I think this is a pipe dream. > > Besides, accurately specified dependency information, including versions, > within a package should suffice. It would be handy if you could also specify > python version compatibility in this, something that setuptools does not > currently support AFAIK.
you can use the Requires-Python metadata though. For KGS I agree that this is a big work, but there's the need to work at a higher level that in your package that is what zc.buildout brought in a way, but at the application level, and with no respect to the OS-level in a way. Si we should find a way to generalize this at Python level imho: being able to develop your package in a known environment. and being able to give that info to the OS. Python frameworks are exploding in a myriad of packags : a Python instalation needs to handle up to a hundreds of public packages now to run a plone site for example > > cheers, > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Tarek Ziadé - Directeur Technique INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632 Bureaux de la Colline - 1 rue Royale - Bâtiment D - 9ème étage 92210 Saint Cloud - France Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04 http://www.ingeniweb.com - une société du groupe Alter Way
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
