Re: [Python-Dev] [Distutils] Static metadata using setup.cfg
David Lyon wrote:
On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers <chris@simplistix.co.uk> wrote:
<mini rant> If Python had a packaging system *and* used it for the standard library, then things like this wouldn't be a problem... The setup.cfg could just say "requires sqlite greater than version x.y.z", and if it was in the standard library, it would be used unless a newer version was needed.
+1
Actually, this was already discussed on this mailing list.
Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev... (CC'ing so they can tell me I'm wrong ;-) )
I suggested that a "requires" section could easily do this, something along the lines of:
[Requires] stdlib=sqlite>=1.5
Tarek, How are requirements spelled for packages in your current setup.cfg? I really don't see why anything should be different for standard library packages (ie: the stdlib= prefix in David's example). Python distributions should just declare all the versions they come with in the same way that whatever-is-being-built by Tarek can introspect in the same way as any other package...
So the concept of having an if/else test for this is superfluous.
Right.
It would also mean it would be possible to release bug fix versions of the standard library packages without having to roll a whole python release.
+1
...which in turn would mean that the standard library is no longer a place where packages go to die...
Better yet, since "python" should be a package as far as the packaging system is concerned, library versions can just say what versions of python they work with.
+1 - good idea
...and for me, the "python" package should be just another package in the distributions dance, called "python" ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
2009/9/8 Chris Withers <chris@simplistix.co.uk>:
I suggested that a "requires" section could easily do this, something along the lines of:
[Requires] stdlib=sqlite>=1.5
Tarek, How are requirements spelled for packages in your current setup.cfg?
Sorry, that's another problem we are dealing with here e.g. How *one* requirement is defined. The .cfg file is just a format that holds values, like you would express them in command line or in arguments. The "How are requirements spelled" part is the changes we will add in PEP 345. The templating part is just here to make these requirements (or anything else) vary, depending on a few environment values, so it can be read without installing the distribution, with a vanilla Python. Please stop cross-posting in other mailing-lists it makes the discussions confusing. there are two discussions, to be talked in distutils-SIG: 1/ static metadata using a setup.cfg.in (the current one) 2/ changes that will occur in PEP 345, to include requirement definitions Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースの岩！
Chris Withers wrote:
David Lyon wrote:
On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers <chris@simplistix.co.uk> wrote:
<mini rant> If Python had a packaging system *and* used it for the standard library, then things like this wouldn't be a problem... The setup.cfg could just say "requires sqlite greater than version x.y.z", and if it was in the standard library, it would be used unless a newer version was needed.
+1
Actually, this was already discussed on this mailing list.
Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev... (CC'ing so they can tell me I'm wrong ;-) )
My recollection of the python-dev discussions was that the outcome was "there isn't even a distutils-sig consensus yet, so it's a little early for python-dev to be sticking its oar in". Also, I don't think providing new metadata *describing* the standard library was particularly controversial - it was more radical ideas of actually breaking up the core distro into separate components that met resistance. Third party installers having the power to easily "replace" standard library modules for more than a single application was also a heavily debated feature (since that way lies unintended coupling and application/library installations that break previously installed applications). It's probably also worth mentioning that on many of these topics there is a recurring communications gap that usually becomes painful for the distutils-sig side as core devs re-ask questions that were hashed out on the distutils list long before. So I would suggest being prepared to summarise and provide links to such discussions when this all becomes settled enough to bring back to the whole of python-dev. The back and forth of an archived mailing list discussion can sometimes be more persuasive than the relatively sanitised summaries that end up in a PEP :) That said, Tarek's response suggests that this still isn't ready for a wider python-dev discussion, so I've set followup-to accordingly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (3)
-
Chris Withers -
Nick Coghlan -
Tarek Ziadé