On Apr 09, 2011, at 06:23 PM, Éric Araujo wrote:
One of the main complaint against setuptools is that having to change your application code because of the packaging tool used was not a > good idea. Having to use require instead of import or resource_whatever instead of open (or get_data, the most sadly underused function in > the stdlib) because you use setuptools instead of distutils was a bad > thing.
As stated in the PEP, having a __version__ attribute in the module is common, so my opinion is that making the packaging tool use that info > is the Right Thing™, and having the dependency in the reverse sense is wrong. I don’t see a problem with having harmless duplication in the *installed* system, once in elle.__version__ and once in the pkgutil metadata database.
I'm including this section because at Pycon, some people did express > an interest in deriving the version number in this direction. I wanted > to capture what that might look like. Since this is an informational > PEP, I think it makes sense to include alternative approaches, but I tend to > agree with you that it will be much more common to define > module.__version__ and derive the metadata from that.
IOW, you can define the version only once, either in your source file or in the setup.cfg file, and the PEP describes how to get that info from the other place. My personal opinion is that the approach using pkgutil.get_distribution should be much less prominent than the one putting the version in the Python code.
It is already though, right? To me anyway the PEP does emphasize setting __version__, but I'm open to specific suggestions.