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. > > 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.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. -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
