On 07/04/2011 12:59, Nick Coghlan wrote:
On Thu, Apr 7, 2011 at 9:10 PM, Michael Foordfuzzyman@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:
- 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,