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)
