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+pyt...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
