On Apr 07, 2011, at 04:53 PM, Nick Coghlan wrote: >What I would like to see the PEP say is that if you don't *have* a >setup.cfg file, then go ahead and embed the version directly in your >Python source file. If you *do* have one, then put the version there >and retrieve it with "pkgutil" if you want to provide a __version__ >attribute.
I'm not convinced there's consensus on that, i.e. that the version string should go in setup.cfg if it exists. It doesn't help that the pkgutil API for doing that is pretty ugly. >Barry is welcome to make a feature request to allow that dependency to >go the other way, with the packaging system reading the version number >out of the source file, but such a suggestion doesn't belong in an >Informational PEP. If such a feature is ever accepted, then the >recommendation in the PEP could be updated. Note that there's really no reason why packaging has to grow a method to do this. It would be a convenience, but not a requirement. For example, I have my own helper function (something like the now elided get_version() code) that digs version strings out of files for my own packages just fine. True, it doesn't handle the full normalized version specification, but I don't care because my version numbers will never look that complex. If yours does, and you don't want to rely on the pkgutil API, or you need it to work even when your module isn't installed, well, write your own code! The Deriving section of the PEP is not the most important part of it, and is not making specific recommendations. If it's not clear that it's only providing examples, or it's distracting, then maybe it's better off being removed, cut down or rewritten. Cheers, -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
