(In reply to Lumír Balhar from comment #0)
> Python 2.7 will reach end-of-life in January 2020, over 9 years after it was
> released. This falls within the Fedora 31 lifetime.
> Packages that depend on Python 2 are being switched to Python 3 or removed
> from Fedora:
I consider this step to be non-helpful and extremistic, to say the least.

> To help planning, we'd like to know the plans for k3d's future. Specifically:
> 
> 
> - What is the reason for the Python2 dependency? (Is it software written in
> Python, or does it just provide Python bindings, or use Python in the build
> system or test runner?) 
This package contains python modules.
 
> - What are the upstream/community plans/timelines regarding Python 3?
This package basically is in "keep-alive mode".

I.e. upstream is alive and is accepting patches, but I am not aware of any active development nor any plans to move to Python 3.

> - What is the guidance for porting to Python 3? (Assuming that there is
> someone who generally knows how to port to Python 3, but doesn't know
> anything about the particular package, what are the next steps to take?)

This package doesn't build with Python 3, basically because of these issues:
a) Its cmake-files do not honor recent Fedora Python (2 + 3) packaging changes.
b) Its cmake-files do not honor Python 3.
c) The source-code is not Python 3 compatible.

So far, I've worked-around a) (Successfully wrt. Python 2) by hacking cmake stuff from inside of the spec-file.

I have preliminary hacks/attempts to address a) (Python3) and c) pending, but no success so far.

Keeping software on Python 2 is entirely possible. If that's the plan, could you file for a FESCo exception, so it is tracked?

k3d's Python 2 dependencies (which would generally need to find a maintainer) are tracked at: https://fedora.portingdb.xyz/pkg/k3d/

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

The current plan is to remove packages with dependency on Python 2 from Fedora 32 in the middle of November 2019. If you want to keep your package in Fedora after that date and you cannot port it to Python 3 yet, you need to request a FESCo exception for the package and all its Python 2 dependencies (even transitive) [1]. If you don't want to maintain it anymore, and nothing in Fedora uses it, you can retire it or just remove the Python 2 part from it (subpackage, module, bindings, etc.).

If you're considering filing the exception request, let us know. We can help (for example, we can help find all the dependencies).

[1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions

(In reply to Lumír Balhar from comment #5)
> The current plan is to remove packages with dependency on Python 2 from
> Fedora 32 in the middle of November 2019.
That's an utterly hostile act against fedora contributors.

> If you're considering filing the exception request, let us know. We can help
> (for example, we can help find all the dependencies).
Instead of pushing around volunteer contributors and direct them to the bureaucracy you have set up, you actually could have (technically) helped - Long time ago!
 
> [1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions
With a large grain of salt, I'll play it nice, an file a request.

>> The current plan is to remove packages with dependency on Python 2 from
>> Fedora 32 in the middle of November 2019.
> That's an utterly hostile act against fedora contributors.

Sorry for that!
We don't want to maintain software that has no upstream support. But we want to do better than just retire python2.
(As always, if you're not happy with this direction, you're welcome to take over python2 maintenance instead.)


>> If you're considering filing the exception request, let us know. We can help
>> (for example, we can help find all the dependencies).
> Instead of pushing around volunteer contributors and direct them to the bureaucracy you have set up, you actually could have (technically) helped - Long time ago!
 
Sorry for the bureaucracy. Keeping this organized isn't straightforward. There are hundreds of packages, many of which we're not familiar with at all. Unfortunately, it's too many to go and port each one. We need to ask for info from maintainers, and prioritize.

k3d depends on boost. When you include transitive and build-time dependencies, boost depends on 45 Python 2 packages: mercurial, PyYAML, mpich, openmpi python-atomicwrites, python-attrs, python-contextlib2, python-coverage, python-dateutil, python-docutils, python-extras, python-fixtures, python-freezegun, python-funcsigs, python-hypothesis, python-linecache2, python-mimeparse, python-mock, python-nose, python-pathlib2, python-pbr, python-pip, python-pretend, python-py, python-scandir, python-scripttest, python-setuptools, python-setuptools_scm, python-six, python-sure, python-testscenarios, python-testtools, python-traceback2, python-unittest2, python-wheel, python-zope-event, python-zope-interface, python-rpm-macros, python-enum34, python-futures, python2, python2-more-itertools, python2-numpy, python2-pluggy, python2-pytest
(We track them at: https://fedora.portingdb.xyz/pkg/k3d/)

Do you know which of these k3d uses directly, and which are (from k3d's point of view) just implementation details of other dependencies? For which ones are maintainers OK with supporting python2, and how long? Which ones need (co-)maintainers?

>> [1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions
> With a large grain of salt, I'll play it nice, and file a request.

Thank you!

The boost maintainer would be very happy to drop Python 2 support: supporting a dual py2/py3 build is "a nightmare". But it is technically possible to keep boost-python2. 

Is it worth keeping python2-boost for freeorion and k3d?

Here is a PR for using `boost169`, which will retain Python 2 support: https://src.fedoraproject.org/rpms/k3d/pull-request/1

See discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1767503

(In reply to Petr Viktorin from comment #9)
> Here is a PR for using `boost169`, which will retain Python 2 support:
> https://src.fedoraproject.org/rpms/k3d/pull-request/1
> 
> See discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1767503

Thanks, Petr. I applied your patch.

Can this BZ now be closed or is k3d still at risc of being shot?

Technically, there's still no exception for it. Are you still planning to file one, or should I?

*** This bug has been marked as a duplicate of bug 1777631 ***