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

2020-07-08 Thread Ondrej Novy
Hi,

st 8. 7. 2020 v 12:14 odesílatel Thomas Goirand  napsal:

> There would be no point doing that, as all what pybuild would be doing
> (ie: setup.py install and unit testing), I'd be overriding it.


it's doing much more, but nevermind.


> The other
> (IMO preferred) way would be to contribute to Pybuild to make it does
> what's needed for these packages, and in a way so that we can also make
> such global change for all OpenStack packages at once.
>

that's even better! Add support for stestr (or whatever is OS using now)
with correct autodetection and you are done.

-- 
Best regards
 Ondřej Nový


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

2020-07-08 Thread Thomas Goirand
On 7/7/20 8:20 AM, Ondrej Novy wrote:
> Hi,
> 
> po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand  > napsal:
> 
> 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. 
> 
> 
> so you could wrap these global things around pybuild, right?

There would be no point doing that, as all what pybuild would be doing
(ie: setup.py install and unit testing), I'd be overriding it. The other
(IMO preferred) way would be to contribute to Pybuild to make it does
what's needed for these packages, and in a way so that we can also make
such global change for all OpenStack packages at once.

I've been thinking about it for a while, but my ideas aren't clear
enough to start something (yet).

Cheers,

Thomas Goirand (zigo)



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

2020-07-07 Thread Ondrej Novy
Hi,

po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand  napsal:

> 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.


so you could wrap these global things around pybuild, right?

-- 
Best regards
 Ondřej Nový


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

2020-07-06 Thread Thomas Goirand
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)