On Monday, April 8, 2019 1:24:40 PM CEST email@example.com wrote:
packages are named I didn't even notice the pypi name is python-subunit and not just subunit.
No, there is no renaming whatsoever. python-subunit project on PyPI (what was the upstream for our package python-python-subunit) was terminated as a project. So, we have completely replaced this package with new (mostly C++) package subunit, which also includes bindings (providing API compatibility) for many scripting languages, Python among them.
I understand this part. yet this "new" package has "python-subunit" as pypi name configured, so it should be pythonX-python-subunit. However, for reasons that are not understandable to me, the new subunit package uses "pythonX- subunit" as package naming. Given that I had a bout 700 packages depending on the old name, I would really like to understand why we're introducing this inconsistency.
I quoted the setup.py name= setting in the previous mail, please have a look there.
So, python-python-subunit package should be completely eliminated by a subpackage from the subunit package (with the new upstream).
Yes, I did that now from devel:languages:python after I noticed this conflict (it was there before, which caused this problem to be hidden for quite some time).
Do we know how complicated API we are talking about? How complicated it would be to patch subunit to work with the new API?
It is near trivial, but that isn't the point. the point is that we're checkin in packages that don't work, and that causes large fallout for our CI. I'm all for getting this fixed, but only if the result actually works.