Open Stack

On 26 June 2015 at 23:01, Matthew Booth <mbooth at redhat.com> wrote:
> I wrote this:
>
> https://review.openstack.org/#/c/195983/1/tools/de-pbr.py,cm
>
> Ideally we'd fix PBR, but this seems to be expected behaviour. Thoughts?

Hi Matt, thanks for raising this. We've had very mixed results trying
to figure out what issues distribution packagers are having with pbr -
we have a couple of mechanisms already for them:
 - you can tag - a tagged commit has the version of the tag
 - you can use PBR_VERSION (per
http://docs.openstack.org/developer/pbr/packagers.html)

The error you complain about in that review is saying that that config
file specifies a version number that *cannot* be satisfied.

Versions have to increase, they can't go backwards. There are several
things that could combine to create this contradiction: for instance,
say you have two commits, B the most recent commit and A the commit
before it. There's also a tag 2014.1.4 that points at A.

B cannot have a version lower than 2014.1.5: because if B had a
version of 2014.1.4, the tag pointing at A would be false. If B had a
version of 2014.1.4a1 or anything like that, B would have a lower
version than A.

But the config file in nova at the time this error was raised says
'The version of the next release WILL BE 2014.1.4'. Thus PBR has been
given contradictory instructions, and throws its hands up in the air.

We could perhaps instead just *ignore* setup.cfg's version line. That
would mean that you'd get 2014.1.5, but this would be very surprising
to folk that have been putting versions in setup.cfg, so we didn't do
that. I don't know if that would solve the issue you were having.

We could remove the version = line from setup.cfg's across the board,
and Doug and Thierry are considering that.

The pbr team (loosely oslo+infra) are very open to discussion about
the right way to do things, for both upstream and packagers, and would
welcome a bug report describing any confusing or problematic situation
you might find yourself in in future.

I know of two important bits of work at the moment; firstly I've
promised to write up a spec about making pbr suitable for use in some
of the Python packaging tools [virtualenv and pip specifically], which
will involve being able to ship sdists that have no setup_requires. I
believe this will be attractive to distribution packagers as well.
Secondly, some folk are interested in supporting local version
segments in the PEP-440 version string - I'm keen on that too, but it
needs (IMNSHO) to align in with the Nova/Cinder etc 'vendor version'
feature from their config files - we should consolidate that logic
into pbr, as its really got nothing to do with any one API server per
se.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud