Open Stack

On 25 March 2016 at 07:25, Chris Dent <cdent+os at 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 <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud