[Python-Dev] PEP 396, Module Version Numbers

[Nick Coghlan]

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']
>
> 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.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia