RetroSearch Browse

Thu Apr 7 13:10:59 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-April/110533.html

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).

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-April/110533.html below:

[Python-Dev] PEP 396, Module Version Numbers