Re: [Python-Dev] packaging location ?
On Thu, 13 Sep 2012 11:14:17 +1000 Nick Coghlan wrote: > On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray > wrote: > > When the removal was being pondered, the possibility of keeping certain > > bits that were more ready than others was discussed. Perhaps the best > > way forward is to put it back in bits, with the most finished (and PEP > > relevant) stuff going in first. That might also give non-packaging > > people bite-sized-enough chunks to actually digest and help with. > > This is the plan I'm going to propose. The previous approach was to > just throw the entirety of distutils2 in there, but there are some > hard questions that doesn't address, and some use cases it doesn't > handle. So, rather than importing it wholesale and making the stdlib > the upstream for distutils2, I believe it makes more sense for > distutils2 to remain an independent project, and we cherry pick bits > and pieces for the standard library's new packaging module as they > stabilise. How is that going to be useful? Most people use distutils / packaging as an application, not a library. If you provide only a subset of the necessary features, people won't use packaging. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Thursday, September 13, 2012 at 5:38 AM, Antoine Pitrou wrote: > Most people use distutils / packaging as > an application, not a library. If you provide only a subset of > the necessary features, people won't use packaging. Not that I think current usage patterns matter since moving from setup.py to a static file, but that's not really true. The wide proliferation of setuptools shows pretty clearly that people are fine using distutils as a library. Even beyond that the popularity of pip shows that as well since very few people even directly interact with setup.py at all except to create the distributions. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On 9/13/12 11:38 AM, Antoine Pitrou wrote: On Thu, 13 Sep 2012 11:14:17 +1000 Nick Coghlan wrote: On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray wrote: When the removal was being pondered, the possibility of keeping certain bits that were more ready than others was discussed. Perhaps the best way forward is to put it back in bits, with the most finished (and PEP relevant) stuff going in first. That might also give non-packaging people bite-sized-enough chunks to actually digest and help with. This is the plan I'm going to propose. The previous approach was to just throw the entirety of distutils2 in there, but there are some hard questions that doesn't address, and some use cases it doesn't handle. So, rather than importing it wholesale and making the stdlib the upstream for distutils2, I believe it makes more sense for distutils2 to remain an independent project, and we cherry pick bits and pieces for the standard library's new packaging module as they stabilise. How is that going to be useful? Most people use distutils / packaging as an application, not a library. If you provide only a subset of the necessary features, people won't use packaging. Regards Antoine. Yeah but we've been too ambitious. Here's my proposal - actually it's Nick's proposal but I want to make sure we're on the same page wrt steps, and I think that addresses Antoine concerns 1. create a new package, called pkglib (or whatever), located at hg .python.org as a new project that just strictly contains : - the PEP implementations - non controversial features like files parser, pypi index browser etc it's doable - since that's what we have done in distutils2. the modules that implements those PEPs are standalone Let's avoid by all means to put the old distutils command logic there. Let's have a strict process on every new thing we're adding there. 2. make pkglib python 2 *and* python 3 compatible - natively, not w/ 2to3 3. make distutils2, distribute, pip, bento, etc. use that and try to share as many bits as possible 4. ask each project to pour in pkglib anything that can be reused by others when 3.4 comes around, I guess we can decide if pkglib can go in or not. That way, we won't have the usual controversy about distutils' command machinery. People will use whatever tool and hopefully this tool will be based on pkgutil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Thu, Sep 13, 2012 at 4:32 AM, Tarek Ziadé wrote: > Here's my proposal - actually it's Nick's proposal but I want to make sure > we're on the same > page wrt steps, and I think that addresses Antoine concerns > > 1. create a new package, called pkglib (or whatever), located at hg > .python.org as a new project that just strictly contains : > > ... > > That way, we won't have the usual controversy about distutils' command > machinery. People will use whatever tool > and hopefully this tool will be based on pkgutil Hopefully it will be based on pkglib (or whatever) rather than pkgutil. ;) --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Thursday, September 13, 2012 at 7:32 AM, Tarek Ziadé wrote: > > Yeah but we've been too ambitious. > > Here's my proposal - actually it's Nick's proposal but I want to make > sure we're on the same > page wrt steps, and I think that addresses Antoine concerns > > 1. create a new package, called pkglib (or whatever), located at hg > .python.org (http://python.org) as a new project that just strictly contains : > > - the PEP implementations > - non controversial features like files parser, pypi index browser etc > > it's doable - since that's what we have done in distutils2. the > modules that implements those PEPs are standalone > > Let's avoid by all means to put the old distutils command logic there. > > Let's have a strict process on every new thing we're adding there. > > > 2. make pkglib python 2 *and* python 3 compatible - natively, not w/ 2to3 > > > 3. make distutils2, distribute, pip, bento, etc. use that and try to > share as many bits as possible > > > 4. ask each project to pour in pkglib anything that can be reused by others I started messing around with yanking some of the parts of distutils2 (things I've been calling packaging primitives for lack of a better word). Don't have anything particularly usable yet, but the approach you're talking about is similar to what I started to do. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On 13 September 2012 12:32, Tarek Ziadé wrote: > Here's my proposal - actually it's Nick's proposal but I want to make sure > we're on the same > page wrt steps, and I think that addresses Antoine concerns > > 1. create a new package, called pkglib (or whatever), located at hg > .python.org as a new project that just strictly contains : > > - the PEP implementations > - non controversial features like files parser, pypi index browser etc > > it's doable - since that's what we have done in distutils2. the modules > that implements those PEPs are standalone +1. I've seen far too many implementation of code that reads/writes RECORD files for instance. They are all subtly different and manage to have incompatible obscure bugs :-( A reference implementation would be an excellent thing. In the stdlib by preference, external for older versions is as good as you can get. The key here is to avoid having packaging tools with any more dependencies than necessary (because there's a bootstrapping issue with installing those dependencies...) > Let's avoid by all means to put the old distutils command logic there. +1 > Let's have a strict process on every new thing we're adding there. Hmm. Agreed up to a point, but please let's not make it so hard to change things that are present that people go off and do their own thing again[1]. OTOH, I agree let's be cautious about adding new things. Once pkglib goes into the stdlib, that's when things get strict. Let's leave a bit of flexibility while the details are thrashed out. > 2. make pkglib python 2 *and* python 3 compatible - natively, not w/ 2to3 +0 > 3. make distutils2, distribute, pip, bento, etc. use that and try to share > as many bits as possible We can't "make" anyone use pkglib, but if it clearly makes it easier to support the standards than implementing them yourself, it should persuade people. And we should certainly advocate supporting PEPs by using the reference implementation rather than reimplementing it yourself. > 4. ask each project to pour in pkglib anything that can be reused by others +1, although again it'll be down to the projects whether they do actually contribute. Also this somewhat contradicts the "be strict" point above, which is why I'm lukewarm on "be strict". Practicality vs purity - getting contributors/users is more important than insisting that everything be standardised before it can be implemented. > when 3.4 comes around, I guess we can decide if pkglib can go in or not. I'd have an explicit goal to be included in 3.4 (so that people can imagine an end to the need for pkgutil being a dependency of their installation tool). But agreed it should not be assumed that this will happen if it's not ready (that was the mistake with packaging). > That way, we won't have the usual controversy about distutils' command > machinery. People will use whatever tool > and hopefully this tool will be based on pkgutil +1. It also means that people will have a much greater incentive to support the new standards, because it should simply be a case of calling the pkglib implementation. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On 9/13/12 2:45 PM, Paul Moore wrote: 4. ask each project to pour in pkglib anything that can be reused by others +1, although again it'll be down to the projects whether they do actually contribute. Also this somewhat contradicts the "be strict" point above, which is why I'm lukewarm on "be strict". Practicality vs purity - getting contributors/users is more important than insisting that everything be standardised before it can be implemented. Let me take back 'strict process' and replace it with: Everything added in pkglib should be a basic feature/implementation that does not force the tools to change the way *they* see their build/release/UI processes. The most sophisticated feature I am thinking about is the set of apis in distutils2.pypi They are APIs to browse and interact with PyPI, and they are useful to many projects, so I think it fits my definition. otho, anything relating to compilation should not be added there, unless it's APIs to get some aggregated info, like on the top of platform/sys/etc Cheers Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unsupported doctest directives in Doc/library/ctypes.rst
In the process of studying the global state of our doctests, I noticed that the doctests in Doc/library/ctypes.rst use the following doctest directives: # doctest: +LINUX # doctest: +WINDOWS However, I'm not able to find evidence that these directives are implemented anywhere. Thus I get an error like the following when trying to parse the file using doctest: "ValueError: line 55 of the doctest for ctypes.rst has an invalid option: '+WINDOWS'" The reST file says this towards the top: "Note: The code samples in this tutorial use :mod:`doctest` to make sure that they actually work. Since some code samples behave differently under Linux, Windows, or Mac OS X, they contain doctest directives in comments."" The farthest back I was able to trace this paragraph was here from April 2006: http://hg.python.org/cpython/rev/0e0e315b4202 in which the docs seem to have been added from reST sources outside the repository (from ctypes 0.9.9.6 upstream -- see the parent changeset). I would like for our docs to be parseable by doctest without error. Possible options seem to include at least (1) changing these directives to normal code comments until we can support these directives in a meaningful way, and (2) calling doctest.register_optionflag() for these directives as no-ops as appropriate to make the errors go away. Does anyone have any thoughts on this? Thanks, --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Thu, Sep 13, 2012 at 9:47 PM, Chris Jerdonek wrote: > On Thu, Sep 13, 2012 at 4:32 AM, Tarek Ziadé wrote: >> Here's my proposal - actually it's Nick's proposal but I want to make sure >> we're on the same >> page wrt steps, and I think that addresses Antoine concerns >> >> 1. create a new package, called pkglib (or whatever), located at hg >> .python.org as a new project that just strictly contains : >> >> ... >> >> That way, we won't have the usual controversy about distutils' command >> machinery. People will use whatever tool >> and hopefully this tool will be based on pkgutil > > Hopefully it will be based on pkglib (or whatever) rather than pkgutil. ;) Actually, I'd be happy to do the rearrangement needed to turn pkgutil into a package rather than the current single module. I think we'd have people breaking out the torches and pitchforks if we ever ended up with modules or packages called packaging, pkglib *and* pkgutil all in the standard library. "distcore" might work, since they're core functionality for distribution more so than they are for packages. Anyway, the essential idea of getting those 4 modules (and support libraries) that almost made it into 3.3 into sufficiently good shape that they can be distributed independently of distutils2 and adopted as a dependency by multiple projects is a good one. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Fri, Sep 14, 2012 at 12:34 AM, Nick Coghlan wrote: > Anyway, the essential idea of getting those 4 modules (and support > libraries) that almost made it into 3.3 into sufficiently good shape > that they can be distributed independently of distutils2 and adopted > as a dependency by multiple projects is a good one. I also like Tarek's suggestion of including the pypi client APIs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
Hi, Le 13/09/2012 10:34, Nick Coghlan a écrit : > Actually, I'd be happy to do the rearrangement needed to turn pkgutil > into a package rather than the current single module. I very much prefer not mixing pkgutil (dealing with packages that you import) and build/distribution/installation support (dealing with packages/bundles/distributions/parcels/stuff that your distribute). Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Fri, Sep 14, 2012 at 12:39 AM, Éric Araujo wrote: > Hi, > > Le 13/09/2012 10:34, Nick Coghlan a écrit : >> Actually, I'd be happy to do the rearrangement needed to turn pkgutil >> into a package rather than the current single module. > > I very much prefer not mixing pkgutil (dealing with packages that you > import) and build/distribution/installation support (dealing with > packages/bundles/distributions/parcels/stuff that your distribute). Tarek started it when he suggested "pkglib" :) I like "distcore" or "distlib", though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Fri, Sep 14, 2012 at 12:39 AM, Éric Araujo wrote: > Hi, > > Le 13/09/2012 10:34, Nick Coghlan a écrit : >> Actually, I'd be happy to do the rearrangement needed to turn pkgutil >> into a package rather than the current single module. > > I very much prefer not mixing pkgutil (dealing with packages that you > import) and build/distribution/installation support (dealing with > packages/bundles/distributions/parcels/stuff that your distribute). Tarek started it when he suggested "pkglib" :) I like "distcore" or "distlib", though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging location ?
On Thu, Sep 13, 2012 at 5:38 AM, Antoine Pitrou wrote: > On Thu, 13 Sep 2012 11:14:17 +1000 > Nick Coghlan wrote: >> On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray >> wrote: >> > When the removal was being pondered, the possibility of keeping certain >> > bits that were more ready than others was discussed. Perhaps the best >> > way forward is to put it back in bits, with the most finished (and PEP >> > relevant) stuff going in first. That might also give non-packaging >> > people bite-sized-enough chunks to actually digest and help with. >> >> This is the plan I'm going to propose. The previous approach was to >> just throw the entirety of distutils2 in there, but there are some >> hard questions that doesn't address, and some use cases it doesn't >> handle. So, rather than importing it wholesale and making the stdlib >> the upstream for distutils2, I believe it makes more sense for >> distutils2 to remain an independent project, and we cherry pick bits >> and pieces for the standard library's new packaging module as they >> stabilise. > > How is that going to be useful? Most people use distutils / packaging as > an application, not a library. If you provide only a subset of > the necessary features, people won't use packaging. Third-party install/packing software (pip, bento, even distribute) can still gradually absorb any standard pieces added to the stdlib for better interoperability and PEP compliance. I'm still strongly in favor of a `pysetup` like command making it into Python too, but in the meantime the top priority should be anything that supports better consistency across existing projects. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst
On Thu, Sep 13, 2012 at 4:00 PM, ezio.melotti wrote: > http://hg.python.org/cpython/rev/76dd082d332e > changeset: 79022:76dd082d332e > branch: 2.7 > parent: 79014:8f847f66a49f > user:Ezio Melotti > date:Fri Sep 14 01:58:33 2012 +0300 > summary: > #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst > accordingly. I also contributed to this. :) --Chris > files: > Doc/ACKS.txt | 231 -- > Doc/about.rst |9 +- > Misc/ACKS | 119 ++- > 3 files changed, 122 insertions(+), 237 deletions(-) > > > diff --git a/Doc/ACKS.txt b/Doc/ACKS.txt > deleted file mode 100644 > --- a/Doc/ACKS.txt > +++ /dev/null > @@ -1,231 +0,0 @@ > -Contributors to the Python Documentation > - > - > -This section lists people who have contributed in some way to the Python > -documentation. It is probably not complete -- if you feel that you or > -anyone else should be on this list, please let us know (send email to > -d...@python.org), and we'll be glad to correct the problem. > - > -.. acks:: > - > - * Aahz > - * Michael Abbott > - * Steve Alexander > - * Jim Ahlstrom > - * Fred Allen > - * A. Amoroso > - * Pehr Anderson > - * Oliver Andrich > - * Heidi Annexstad > - * Jesús Cea Avión > - * Manuel Balsera > - * Daniel Barclay > - * Chris Barker > - * Don Bashford > - * Anthony Baxter > - * Alexander Belopolsky > - * Bennett Benson > - * Jonathan Black > - * Robin Boerdijk > - * Michal Bozon > - * Aaron Brancotti > - * Georg Brandl > - * Keith Briggs > - * Ian Bruntlett > - * Lee Busby > - * Arnaud Calmettes > - * Lorenzo M. Catucci > - * Carl Cerecke > - * Mauro Cicognini > - * Gilles Civario > - * Mike Clarkson > - * Steve Clift > - * Dave Cole > - * Matthew Cowles > - * Jeremy Craven > - * Andrew Dalke > - * Ben Darnell > - * L. Peter Deutsch > - * Robert Donohue > - * Fred L. Drake, Jr. > - * Josip Dzolonga > - * Jeff Epler > - * Michael Ernst > - * Blame Andy Eskilsson > - * Carey Evans > - * Martijn Faassen > - * Carl Feynman > - * Dan Finnie > - * Hernán Martínez Foffani > - * Stefan Franke > - * Jim Fulton > - * Peter Funk > - * Lele Gaifax > - * Matthew Gallagher > - * Gabriel Genellina > - * Ben Gertzfield > - * Nadim Ghaznavi > - * Jonathan Giddy > - * Shelley Gooch > - * Nathaniel Gray > - * Grant Griffin > - * Thomas Guettler > - * Anders Hammarquist > - * Mark Hammond > - * Harald Hanche-Olsen > - * Manus Hand > - * Gerhard Häring > - * Travis B. Hartwell > - * Tim Hatch > - * Janko Hauser > - * Ben Hayden > - * Thomas Heller > - * Bernhard Herzog > - * Magnus L. Hetland > - * Konrad Hinsen > - * Stefan Hoffmeister > - * Albert Hofkamp > - * Gregor Hoffleit > - * Steve Holden > - * Thomas Holenstein > - * Gerrit Holl > - * Rob Hooft > - * Brian Hooper > - * Randall Hopper > - * Mike Hoy > - * Michael Hudson > - * Eric Huss > - * Jeremy Hylton > - * Roger Irwin > - * Jack Jansen > - * Philip H. Jensen > - * Pedro Diaz Jimenez > - * Kent Johnson > - * Lucas de Jonge > - * Andreas Jung > - * Robert Kern > - * Jim Kerr > - * Jan Kim > - * Kamil Kisiel > - * Greg Kochanski > - * Guido Kollerie > - * Peter A. Koren > - * Daniel Kozan > - * Andrew M. Kuchling > - * Dave Kuhlman > - * Erno Kuusela > - * Ross Lagerwall > - * Thomas Lamb > - * Detlef Lannert > - * Piers Lauder > - * Glyph Lefkowitz > - * Robert Lehmann > - * Marc-André Lemburg > - * Ross Light > - * Ulf A. Lindgren > - * Everett Lipman > - * Mirko Liss > - * Martin von Löwis > - * Fredrik Lundh > - * Jeff MacDonald > - * John Machin > - * Andrew MacIntyre > - * Vladimir Marangozov > - * Vincent Marchetti > - * Westley Martínez > - * Laura Matson > - * Daniel May > - * Rebecca McCreary > - * Doug Mennella > - * Paolo Milani > - * Skip Montanaro > - * Paul Moore > - * Ross Moore > - * Sjoerd Mullender > - * Dale Nagata > - * Michal Nowikowski > - * Steffen Daode Nurpmeso > - * Ng Pheng Siong > - * Koray Oner > - * Tomas Oppelstrup > - * Denis S. Otkidach > - * Zooko O'Whielacronx > - * Shriphani Palakodety > - * William Park > - * Joonas Paalasmaa > - * Harri Pasanen > - * Bo Peng > - * Tim Peters > - * Benjamin Peterson > - * Christopher Petrilli > - * Justin D. Pettit > - * Chris Phoenix > - * François Pinard > - * Paul Prescod > - * Eric S. Raymond > - * Edward K. Ream > - * Terry J. Reedy > - * Sean Reifschneider > - * Bernhard Reiter > - * Armin Rigo > - * Wes Rishel > - * Armin Ronacher > - * Jim Roskind > - * Guido van Rossum > - * Donald Wallace Rouse II > - * Mark Russell > - * Nick Russo > - * Chris Ryland > - * Constantina S. > - * Hugh Sasse > - * Bob Savage
Re: [Python-Dev] [Python-checkins] cpython (2.7): #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst
On Fri, Sep 14, 2012 at 2:22 AM, Chris Jerdonek wrote: > On Thu, Sep 13, 2012 at 4:00 PM, ezio.melotti > wrote: >> http://hg.python.org/cpython/rev/76dd082d332e >> changeset: 79022:76dd082d332e >> branch: 2.7 >> parent: 79014:8f847f66a49f >> user:Ezio Melotti >> date:Fri Sep 14 01:58:33 2012 +0300 >> summary: >> #15437, #15439: merge Doc/ACKS.txt with Misc/ACKS and modify Doc/about.rst >> accordingly. > > I also contributed to this. :) > Yes, with all these ACKS and names I forgot to mention yours in the commit message :) Thanks again for writing the script that automatically merged all the names! Best Regards, Ezio Melotti > --Chris > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
