(original) (raw)
On 4/6/2011 7:26 AM, Nick Coghlan wrote:On Wed, Apr 6, 2011 at 6:22 AM, Glenn Linderman <v+python@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.