On 4 May 2015 at 08:59, Steve Baker <[email protected]> wrote: > On 02/05/15 07:06, Robert Collins wrote: >> >> On 2 May 2015 at 04:17, Doug Hellmann <[email protected]> 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.
So, we've got a design requirements mismatch here, and should give this the same care we do other decisions - I've set up https://etherpad.openstack.org/p/heat-plugin-pbr to start capturing your desires, and also to summarise the pbr constraints that led to where we are today, from there we can work forward. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
