[Python-Dev] PEP 396, Module Version Numbers

[Glenn Linderman]

On 4/6/2011 7:26 AM, 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.

I thought that might be part of the answer :)  But that, and below, seem 
to indicate that use of "packaging" suddenly becomes a requirement for 
all modules that want to include versions.  The packaging of "version" 
inside a version of "packaging" implies more dependencies on a larger 
body of code for a simple function.


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

OK, I just recalled some discussion about multiple coexisting versions 
in past time, not that they produced any conclusion that such should or 
would ever be implemented.

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

So, no support for single .py file modules, then?

If "packaging" truly is the only thing that knows the version of 
something, and "version" lives in "packaging", then perhaps packaging 
"__version__" as part of the module is inappropriate, and the API to 
obtain the version of a module should be inside "packaging" with the 
module (or its name) as a parameter, rather than asking the module, 
which may otherwise not need a dependency on the internals of 
"packaging" except to obtain its own version, which, it doesn't likely 
need for its own use anyway, except to report it.

Which is likely why Barry offered so many choices as to where the 
version of a package or module might live in the first place.

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/after it gets loaded (the latter still required 
some runtime dependency on code from the packaging system).  A line like 
the following in some designated-to-"packaging" source file could be 
replaced during packaging:

__version__ = "7.9.7xxxx" # replaced by "packaging"

could be used for source codes that use "packaging" which would replace 
it by the version from setup.cfg during the packaging process, whereas a 
module that doesn't use "packaging" would put in the real version, and 
avoid the special comment.  The reason the fake version would have a 
(redundant) number would be to satisfy dependencies during 
pre-"packaging" testing.  (The above would add a new parsing requirement 
to "version" for "xxxx" at the end.  Something different than "dev" so 
that development releases that still go through the packaging process 
are still different than developers test code.  "packaging" should 
probably complain if the versions are numerically different and the 
version in the source file doesn't have "xxxx" or doesn't exactly match 
the version in setup.cfg, and if the special comment is not found.)

Caveat: I'm not 100% clear on when/how any of "distutils", "setuptools", 
or "packaging" are invoked (I was sort of waiting for the dust to settle 
on "packaging" to learn how to use this latest way of doing things), but 
based on historical experience with other systems, and expectations 
about how things "should" work, I would expect that a packaging system 
is something that should be used after a module is complete, to wrap it 
up for distribution and installation, but that the module itself should 
not have significant knowledge of or dependency on such a packaging 
system, so that when the module is invoked at runtime, it doesn't bring 
overhead of such packaging systems to the runtime.  I've seen the 
setuptools "egg" where the module stays inside the egg after being 
installed, and while that might have benefits for reducing the installed 
file count, and perhaps other benefits, I've not tried to figure out 
whether the module is dependent on "setuptools" or whether the 
"setuptools" just provides the benefits mentioned, without the module 
needing to be dependent on it, but still it seems the application winds 
up being dependent on some "setuptools" stuff at runtime, when it uses 
such a module.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110406/c7874896/attachment.html>