> - faster build time (no need to test with Python 2, so less chances of
> build failure).
>
> build is done once, customer happiness is for years (buster lifetime).
More work ...
> - no chance to have any Python 2 packages installed, so we're sure we're
> on a full Python 3 stack (in my current setup, unfortunately some Python
> 2 packages are still pulled). This may go on for another 3 years if we
> don't remove Python 2 now, with the added issue that it will pull
> *older* version of clients if selecting Python 2 and if we still have
> them in Buster (ie: case of OpenStack backports on top of Stable).
>
> so let's fix packages to not pull Py2 if it's not needed.
More work...
> - packaging and decrufting will take a long time, so we'd better start
> early. Especially if we want to do it the proper way, without breaking
> any reverse (build-)dependency that are outside of OpenStack.
>
> more than one release cycle? I'm sure we can do it during Bullseye. And
> we will do it for non-OS Python packages too. Better is to do removing
> in earlier phase of development cycle.
And even more work...
There's btw a bunch of RC bugs in the BTS that I would love to get
fixed. Anyone up for contributing that?
This was part of a non-formal discussion with Ubuntu people, I'm not
sure it would be right to say with who, but I'm sure you can guess. We
can discuss with that person again and see what he says now, as maybe
things have changed since that last conversation. So no, I don't have
any formal announcement/links to support that it will happen in Ubuntu
for Rocky.
Now, what needs to be accounted, is how many people use Py2 clients (and
of course, by that, I mean the Python modules, not the cli). To answer
that question, we have unfortunately no data except your own case.
But is the whole set made of just one? Or more? Impossible to say...
Which is why I asked you how much time it would take for fixing the
situation in your own company, as it could be a good example. How many
months do you need? 6 months? A year? It'd be super nice if you could
explain your use case in more details, and tell what your code base is
about. Though maybe you can't do it publicly? Or even, maybe you can't
tell me? I would understand in both cases. But if you can explain, it
would help understanding at least your use case, which may be similar to
others.