[Python-Dev] PEP 396, Module Version Numbers

[Michael Foord]

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<v+python at g.nevcal.com>  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.
>>
>>> On 4/5/2011 11:52 AM, Barry Warsaw wrote:
>>>
>>>      DEFAULT_VERSION_RE = re.compile(r'(?P<version>\d+\.\d(?:\.\d+)?)')
>>>
>>>      __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 information is *only* available 
> if the package has been installed by "packaging", and so isn't 
> available for the parts of my pre-build process like building the 
> documentation (which import the version number to put into the docs).
>

And in fact it would make the module itself unimportable unless 
installed by "packaging", so not compatible with other installation 
methods (including the ever-loved 'just drop it somewhere on sys.path) 
or earlier versions of Python that don't have the required apis (or 
don't have packaging installed).

So I don't think recommending 
"pkgutil.get_distribution('elle').metadata['version']" as a way for 
packages to provide version information is good advice.

All the best,

Michael Foord

> Currently all my packages have the canonical version number 
> information in the package itself using:
>
>     __version__ = '1.2.3'
>
> Anything that needs the version number, including setup.py for upload 
> to pypi, has one place to look for it and it doesn't depend on any 
> other tools or processes. If switching to "packaging" prevents me from 
> doing this then it will inhibit me using "packaging".
>
> What I may have to do is use a python script that will generate the 
> static metadata, which is not such a bad thing I guess as it will only 
> need to be executed at package build time. I won't be switching to 
> that horrible technique for specifying versions within my packages 
> though.
>
> All the best,
>
> Michael
>>> The RE as given won't match alpha, beta, rc, dev, and post suffixes 
>>> that are
>>> discussed in POP 386.
>> Indeed, I really don't like the RE suggestion - better to tell people
>> to just move the version info into the static config file and use
>> pkgutil to make it available as shown. That solves the build time vs
>> install time problem as well.
>>
>>> Nor will it match the code shown and quoted for the alternative 
>>> distutils2
>>> case.
>>>
>>>
>>> Other comments:
>>>
>>> Are there issues for finding and loading multiple versions of the same
>>> module?
>> No, you simply can't do it. Python's import semantics are already
>> overly complicated even without opening that particular can of worms.
>>
>>> Should it be possible to determine a version before loading a 
>>> module?  If
>>> yes, the version module would have to be able to find a parse version
>>> strings in any of the many places this PEP suggests they could be... 
>>> so that
>>> would be somewhat complex, but the complexity shouldn't be used to 
>>> change
>>> the answer... but if the answer is yes, it might encourage fewer 
>>> variant
>>> cases to be supported for acceptable version definition locations 
>>> for this
>>> PEP.
>> Yep, this is why the version information should be in the setup.cfg
>> file, and hence available via pkgutil without loading the module
>> first.
>>
>> Cheers,
>> Nick.
>>
>
>


-- 
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html