[openstack-dev] [all][heat] pbr 0.11 released. Must read if you encounter pbr.version.SemanticVersion(XXXX), but target version ... errors
Steve Baker
sbaker at redhat.com
Sun May 3 20:59:28 UTC 2015
On 02/05/15 07:06, Robert Collins wrote:
> On 2 May 2015 at 04:17, Doug Hellmann <doug at doughellmann.com> wrote:
>> Excerpts from Robert Collins's message of 2015-05-01 10:59:49 +1200:
>>> pbr 0.11 is finally released (now that Kilo is out :).
>>>
>>> This brings in more support to ensure that our version numbers are
>>> monotonically increasing.
>>>
>>> Mostly this should be unintrusive (but please do read the docs -
>>> http://docs.openstack.org/developer/pbr/#version).
> ...
>
>> It would be good to make sure this is in the pbr documentation, too.
> It is, at the link I gave. If its not clear enough, please do help me
> understand how, since having clear docs is kindof important :)
>
> I'd also like to do a little postmortem - here's the fallout I've
> heard of from pbr's 0.11 release (which is > 1yr of inventory, so
> kindof a big deal).
>
...
>
> Lastly, and still unresolved, heat's contrib plugin versions
> (introduced in March) are deliberately different to the git history,
> and thats a use case that pbr hasn't ever supported (multiple version
> timelines in one git tree). https://review.openstack.org/#/c/162311/
> introduced the versions. https://bugs.launchpad.net/heat/+bug/1450733
> is the bug for this.
Our contrib plugins are not distributed with the heat release and are
come with a very limited notion of being supported. Operators who want
to install any are expected to git-clone to the desired revision and
either cp -r to /usr/lib/heat (our original plugin mechanism) or
pip-install (so the plugin can be picked up by stevedore).
Specifying the version in setup.cfg was added to stop pbr complaining
about the lack of version, and to give operators some way of managing
what version of what they have installed.
We would prefer to keep the contrib plugins in-tree since it lets us run
their unit tests in the standard gate job, and allows them to evolve
with internal API additions. I fully realize that having mini packages
in sub-directories is ... unique.
What I think I would like is a way to tell pbr to ignore git and take
the overridden version from setup.cfg. Having declarative setup is nice,
but another option would be to just switch to plain setuptools - these
are not complicated packages.
More information about the OpenStack-dev
mailing list