Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

[Thomas Goirand <zigo@debian.org>]

On 6/29/20 8:34 AM, Ondrej Novy wrote:
> for my packages (i'm uploader): no, sorry.
> 
> Reasons:
> 1. I hate openstack-pkg-tools
> 2. I like pybuild
> 3. you hate pybuild and don't want to use it

I thought about this for a long time, thinking if I should leave it
unanswered or not. Finally, I have the opinion I can't let it blank.

You are so focus on nit-picking cosmetic fixes, that you are failing to
see the big picture. The same way Daniel did when he told me that
pybuild is "superior" and that I shouldn't waste my time working on my
own tooling. At least 2 others also asked, so maybe it's time to explain.

This isn't about hating or loving pybuild. This is all about being able
to control how this set of packages are build globally (the whole set of
packages. Let me explain why this is important using 3 examples, and
hopefully you'll get where I am at.

A few OpenStack releases ago, most packages migrated away from
testrepository to stestr. For good, because I believe stestr is better.
Anwyay, that's not the point. The point is, the only thing I had to do
to fix it, was to fix pkgos-dh_auto_test, and in there, check if a
.stestr.conf is present. If it is there, pkgos-dh_auto_test just use stestr.

The same way, some packages need to be installed, with a correct
egg-info and entrypoint, otherwise, unit tests are failing. So I could
change that in openstack-pkg-tools.

A 3rd example from last week: now, when unit tests are failing,
openstack-pkg-tools displays the output of "pip3 freeze", so I can do
report upstream more easily.

Each time, for all of these changes, I had to do a single unique change,
in a single place, without affecting other packages in the archive.

Hoping this explains well enough my choice, so that it makes sense to
everyone.

Cheers,

Thomas Goirand (zigo)