On 25 March 2016 at 07:25, Chris Dent <cdent...@anticdent.org> wrote: > On Thu, 24 Mar 2016, Doug Hellmann wrote: > > [good explanation snipped] > > Thanks for the detailed explanation. > > As with so many of these bits of automation they come with a variety > of compromises. After a while it starts to seem like maintaining > those compromises becomes as important as solving the original goal. > >>> [1] The fact that I can't look in the code for __version__ gives me >>> rage face. >> >> >> Having a __version__ inside the package actually has no bearing on >> what version the packaging system thinks is associated with the >> dist. The name is just a convention some projects have used. Rather >> than hard-coding a value, it's better to use pkg_resources to ask >> for the version of the current package. > > > Yeah, I know. I guess I have become accustomed to __version__ as the > canonical source of version authority (used by tooling) because...hrmmm > what's the best way to put this...it's clear, it's just _there_.
There's a stock recipe for pbr using projects that lets you have a https://www.python.org/dev/peps/pep-0396/ compliant __version__ (even though that PEP is deferred :)) which will use either pkg_resources metadata, or pep 345 metadata, or git history, depending on whats available. Thats entirely suitable for querying via automation (import the module, consult mod.__version__). Or you can alternatively query the standard (https://www.python.org/dev/peps/pep-0345/ ) metadata generated from python setup.py egg_info, if you prefer. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
