Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 12, 2011, at 10:14 PM, Laura Creighton wrote: >In a message of Tue, 12 Apr 2011 15:56:32 EDT, Barry Warsaw writes: > >>The Deriving section of the PEP is not the most important part of it, and >> is >>not making specific recommendations. If it's not clear that it's only >>providing example

Re: [Python-Dev] PEP 396, Module Version Numbers

In a message of Tue, 12 Apr 2011 15:56:32 EDT, Barry Warsaw writes: >The Deriving section of the PEP is not the most important part of it, and > is >not making specific recommendations. If it's not clear that it's only >providing examples, or it's distracting, then maybe it's better off being >re

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 07, 2011, at 09:13 AM, Toshio Kuratomi wrote: >Barry -- I think we want to talk about NormalizedVersion.from_parts() rather >than parse_version(). See my previous follow up. It probably makes sense to be explicit in one PEP or the other, but... >So you can't escape needing a function to

Re: [Python-Dev] PEP 396, Module Version Numbers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Apr 06, 2011, at 11:04 AM, John Arbash Meinel wrote: >> In other words, parse_version will return a tuple for each version string, >> that is compatible with StrictVersion but also accept arbitrary version and >> deal with them so they can be com

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 07, 2011, at 04:53 PM, Nick Coghlan wrote: >What I would like to see the PEP say is that if you don't *have* a >setup.cfg file, then go ahead and embed the version directly in your >Python source file. If you *do* have one, then put the version there >and retrieve it with "pkgutil" if you w

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 06, 2011, at 09:55 PM, Glenn Linderman wrote: >The PEP doesn't mention PyPI, and at present none of the modules there use >"packaging" :) So it wasn't obvious to me that the PEP applies only to PyPI, >and I have used modules that were not available from PyPI yet were still >distributed and

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 07, 2011, at 02:08 PM, Nick Coghlan wrote: >(Also, tsk, tsk, Barry for including Standards track proposals in an >Informational PEP!) Is that really illegal? :) >P.S. A nice coincidental progression: PEP 376, 386 and 396 are all >related to versioning and package metadata time-machine-ly

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 07, 2011, at 12:51 PM, Michael Foord wrote: >So I don't think recommending >"pkgutil.get_distribution('elle').metadata['version']" as a way for packages >to provide version information is good advice. I want to make it clear that this section of the PEP is intended only to provide some cho

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 07, 2011, at 09:59 PM, Nick Coghlan wrote: >It sounds like part of the PEP needs another trip through >distutils-sig. An informational PEP really shouldn't be advocating >standard library changes, but it would make sense for this point of >view to inform any updates to PEP 386 (the version

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 09, 2011, at 06:23 PM, Éric Araujo wrote: >> One of the main complaint against setuptools is that having to change >> your application code because of the packaging tool used was not a > good >> idea. Having to use require instead of import or resource_whatever >> instead of open (or get_d

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 07, 2011, at 12:10 PM, Michael Foord wrote: >>> On 4/5/2011 11:52 AM, Barry Warsaw wrote: >>> >>> DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)') >>> >>> __version__ = pkgutil.get_distribution('elle').metadata['version'] >>> > >I really dislike this way of specifying the

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 07, 2011, at 12:26 AM, Nick Coghlan wrote: >> On 4/5/2011 11:52 AM, Barry Warsaw wrote: >> >> DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)') >> >> __version__ = pkgutil.get_distribution('elle').metadata['version'] >> >> The RE as given won't match alpha, beta, rc, dev, an

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 10, 2011, at 08:52 AM, Ben Finney wrote: >Nitpick: Please call these “version strings”. A version string is hardly >ever just one number, and not in the general case anyway. The PEP title does say version *numbers* (plural), and that seems more general than using 'strings' here. >Emil

Re: [Python-Dev] PEP 396, Module Version Numbers

On Apr 05, 2011, at 01:22 PM, Glenn Linderman wrote: >On 4/5/2011 11:52 AM, Barry Warsaw wrote: >> DEFAULT_VERSION_RE = re.compile(r'(?P\d+\.\d(?:\.\d+)?)') >> __version__ = pkgutil.get_distribution('elle').metadata['version'] > >The RE as given won't match alpha, beta, rc, dev, and post

Re: [Python-Dev] PEP 396, Module Version Numbers

"P.J. Eby" writes: > At 03:24 PM 4/10/2011 +, exar...@twistedmatrix.com wrote: > >On 04:02 am, p...@telecommunity.com wrote: > >>At 08:52 AM 4/10/2011 +1000, Ben Finney wrote: > >>>This is an often-overlooked case, I think. The unspoken assumption is > >>>often that ``setup.py`` is a suitable

Re: [Python-Dev] PEP 396, Module Version Numbers

At 03:24 PM 4/10/2011 +, exar...@twistedmatrix.com wrote: On 04:02 am, p...@telecommunity.com wrote: At 08:52 AM 4/10/2011 +1000, Ben Finney wrote: This is an often-overlooked case, I think. The unspoken assumption is often that ``setup.py`` is a suitable place for the overall version strin

Re: [Python-Dev] PEP 396, Module Version Numbers

On 04:02 am, p...@telecommunity.com wrote: At 08:52 AM 4/10/2011 +1000, Ben Finney wrote: This is an often-overlooked case, I think. The unspoken assumption is often that ``setup.py`` is a suitable place for the overall version string, but this is not the case when that string must be read by no

Re: [Python-Dev] PEP 396, Module Version Numbers

At 08:52 AM 4/10/2011 +1000, Ben Finney wrote: This is an often-overlooked case, I think. The unspoken assumption is often that ``setup.py`` is a suitable place for the overall version string, but this is not the case when that string must be read by non-Python programs. If you haven't used the

Re: [Python-Dev] PEP 396, Module Version Numbers

Howdy Barry, Nitpick: Please call these “version strings”. A version string is hardly ever just one number, and not in the general case anyway. I'd like to suggest another user story: Barry Warsaw writes: > User Stories > Emily maintains a package consisting of programs and

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/9/2011 9:23 AM, Éric Araujo wrote: Hi, Le 06/04/2011 23:58, Glenn Linderman a écrit : On 4/6/2011 7:26 AM, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When T

Re: [Python-Dev] PEP 396, Module Version Numbers

Hi, Le 07/04/2011 13:10, Michael Foord a écrit : On 4/5/2011 11:52 AM, Barry Warsaw wrote: __version__ = pkgutil.get_distribution('elle').metadata['version'] I really dislike this way of specifying the version. For a start it is really ugly. More importantly it means the version informa

Re: [Python-Dev] PEP 396, Module Version Numbers

Hi, Le 06/04/2011 23:58, Glenn Linderman a écrit : On 4/6/2011 7:26 AM, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When Tarek lands "packaging" (i.e. what distuti

Re: [Python-Dev] PEP 396, Module Version Numbers

On Wed, Apr 06, 2011 at 11:04:08AM +0200, John Arbash Meinel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > ... > > #. ``__version_info__`` SHOULD be of the format returned by PEP 386's > >``parse_version()`` function. > > The only reference to parse_version in PEP 386 I coul

Re: [Python-Dev] PEP 396, Module Version Numbers

On 07/04/2011 12:59, Nick Coghlan wrote: On Thu, Apr 7, 2011 at 9:10 PM, Michael Foord wrote: I really dislike this way of specifying the version. For a start it is really ugly. More importantly it means the version information is *only* available if the package has been installed by "packagin

Re: [Python-Dev] PEP 396, Module Version Numbers

On Thu, Apr 7, 2011 at 9:10 PM, Michael Foord wrote: > I really dislike this way of specifying the version. For a start it is > really ugly. > > More importantly it means the version information is *only* available if the > package has been installed by "packaging", and so isn't available for the

Re: [Python-Dev] PEP 396, Module Version Numbers

On Thu, 07 Apr 2011 12:10:59 +0100 Michael Foord wrote: > On 06/04/2011 15:26, Nick Coghlan wrote: > > On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman > > wrote: > >> With more standardization of versions, should the version module be > >> promoted > >> to stdlib directly? > > When Tarek lands

Re: [Python-Dev] PEP 396, Module Version Numbers

On 07/04/2011 12:10, Michael Foord wrote: On 06/04/2011 15:26, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When Tarek lands "packaging" (i.e. what distutils2 become

Re: [Python-Dev] PEP 396, Module Version Numbers

On 06/04/2011 15:26, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When Tarek lands "packaging" (i.e. what distutils2 becomes in the Python 3.3 stdlib), the standardise

Re: [Python-Dev] PEP 396, Module Version Numbers

On Thu, Apr 7, 2011 at 5:05 PM, Glenn Linderman wrote: > On 4/6/2011 11:53 PM, Nick Coghlan wrote: > They all use distutils (or setuptools or distutils2) though, which is > what packaging replaces. > > (Sorry for not making that clear - it's easy to forget which aspects > of these issues aren't co

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/6/2011 11:53 PM, Nick Coghlan wrote: On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman wrote: __version__ = "7.9.7" # replaced by "packaging" If you don't upload your module to PyPI, then you can do whatever you want with your versioning info. If you *do* upload it to PyPI, then part of

Re: [Python-Dev] PEP 396, Module Version Numbers

On Thu, Apr 7, 2011 at 2:55 PM, Glenn Linderman wrote: > __version__ = "7.9.7" # replaced by "packaging" > > If you don't upload your module to PyPI, then you can do whatever you > want with your versioning info. If you *do* upload it to PyPI, then > part of doing so properly is to package it

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/6/2011 9:08 PM, Nick Coghlan wrote: On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman wrote: Perhaps a different technique would be that if packaging is in use, that it could somehow inject the version from setup.cfg into the module, either by tweaking the source as it gets packaged, or inst

Re: [Python-Dev] PEP 396, Module Version Numbers

On Thu, Apr 7, 2011 at 7:58 AM, Glenn Linderman wrote: > Perhaps a different technique would be that if packaging is in use, that it > could somehow inject the version from setup.cfg into the module, either by > tweaking the source as it gets packaged, or installed, or tweaking the > module as/aft

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/6/2011 7:26 AM, Nick Coghlan wrote: On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: With more standardization of versions, should the version module be promoted to stdlib directly? When Tarek lands "packaging" (i.e. what distutils2 becomes in the Python 3.3 stdlib), the standardise

Re: [Python-Dev] PEP 396, Module Version Numbers

On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman wrote: > With more standardization of versions, should the version module be promoted > to stdlib directly? When Tarek lands "packaging" (i.e. what distutils2 becomes in the Python 3.3 stdlib), the standardised version handling will come with it. >

Re: [Python-Dev] PEP 396, Module Version Numbers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... > #. ``__version_info__`` SHOULD be of the format returned by PEP 386's >``parse_version()`` function. The only reference to parse_version in PEP 386 I could find was the setuptools implementation which is pretty odd: > > In other words, pa

Re: [Python-Dev] PEP 396, Module Version Numbers

On 4/5/2011 11:52 AM, Barry Warsaw wrote: #. Module version numbers SHOULD conform to the normalized version format specified in PEP 386 [6]_. From PEP 386: Roadmap Distutils will deprecate its existing versions class in favor of Normali

[Python-Dev] PEP 396, Module Version Numbers

I just checked in PEP 396, Module Version Numbers. This is an informational PEP describing how to specify version numbers using the __version__ attribute. This has already made one round through distutils-sig so it's time to post it here. Comments welcome of course! Cheers, -Barry P.S. Yeah, I