On Apr 07, 2011, at 09:59 PM, Nick Coghlan wrote: >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).
I'm certainly open to any suggestions from distutils-sigsters, though I'm not sure the PEP needs to be discussed there exclusively at this point. >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" I like that. Given the recommendations in PEP 396, I think it's more in scope of the distutils-sig, and the various related PEPs to define the details of how that would work. I'd be happy to update the Deriving section of PEP 396 with any such recommendations. That section isn't meant to be definitive or even all-encompassing. It's just meant to give some examples of how you could do things in your own modules. -Barry
signature.asc
Description: PGP signature
_______________________________________________ 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
