On 07/04/2011 12:59, Nick Coghlan wrote: > On Thu, Apr 7, 2011 at 9:10 PM, Michael Foord<fuzzyman at voidspace.org.uk> wrote: >> 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. > It sounds like part of the PEP needs another trip through > distutils-sig. An informational PEP really shouldn't be advocating > standard library changes, but it would make sense for this point of > view to inform any updates to PEP 386 (the version handling > standardisation PEP). > > As I see it, there appear to be two main requests: > 1. Normalised version parsing and comparison should be available even > if packaging itself is not installed (e.g. as part of pkgutil) > 2. packaging should support extraction of the version metadata from > the source files when bundling a package for distribution > > On point 2, rather than requiring that it be explicitly requested, I > would suggest the following semantics for determining the version when > bundling a package ready for distribution: > > - if present in the metadata, use that > - if not present in the metadata, look for __version__ in the module > source code (or the __init__ source code for an actual package) > - otherwise warn the developer that no version information has been > provided so it is automatically being set to "0.0.0a0" > This sounds good to me. As an added consideration the suggested technique may not work for tools like py2exe / py2app, embedded python and alternative implementations - which may not have the full "pacakging" machinery available. All the best, Michael Foord > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4