[Python-Dev] PEP 396, Module Version Numbers (original) (raw)

Barry Warsaw barry at python.org
Tue Apr 12 21:08:16 CEST 2011

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 resourcewhatever instead of open (or getdata, 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. Barry’s reply: 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.getdistribution 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.

-Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20110412/25e1641b/attachment.pgp>

More information about the Python-Dev mailing list