Bug 1737933 - gimp depends on Python 2
Summary: gimp depends on Python 2
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gimp
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1739543 1739544 1737988
Blocks: F31_PY2REMOVAL 1738968 1751502
TreeView+ depends on / blocked
 
Reported: 2019-08-06 11:42 UTC by Lumír Balhar
Modified: 2019-10-03 17:00 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Lumír Balhar 2019-08-06 11:42:20 UTC
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: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages
Python 2 will be retired in Fedora 32: https://fedoraproject.org/wiki/Changes/RetirePython2

To help planning, we'd like to know the plans for gimp'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?) 

- What are the upstream/community plans/timelines regarding 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 bug is filed semi-automatically, and might not have all the context specific to gimp.
If you need anything from us, or something is unclear, please mention it here.

Thank you.

Comment 1 Ben Cotton 2019-08-13 17:08:08 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 2 Ben Cotton 2019-08-13 17:50:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 3 Lumír Balhar 2019-08-14 08:50:43 UTC
Please answer the above questions. If you don't the package can be orphaned: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages

If you need any information or help, please let us know.

Comment 4 Josef Ridky 2019-08-14 09:08:05 UTC
Unfortunately, GIMP upstream don't plan to switch from Python2 to Pyton3 in GIMP-2.10 release cycle and GIMP without Python2 support looses a lot from it's functionality.

What are our options for f31?

We have gimp-module available, so would it be possible to use Python 2 as module in f31+ releases?

What we should do with rpms/gimp fXX branches?

Comment 5 Petr Viktorin 2019-08-14 11:00:22 UTC
Hi,
Fedora 31 (and lower) should stay as it is.

For Fedora 32, AFAICS best option is to file a FESCo exception for GIMP and its dependencies.

We track the dependencies here: https://fedora.portingdb.xyz/grp/gimp/
Currently gimp pulls in 49 packages as transitive dependencies. Many of those could probably be trimmed. Could you take a look at the list and check which ones are essential for Gimp to run?

Comment 6 Lumír Balhar 2019-08-15 06:35:54 UTC
Petr provided the info.

Comment 7 Josef Ridky 2019-08-19 12:30:31 UTC
From GIMP perspective, the most important are python2-devel, pygobject2, gtk2 and pygtk2.

From GIMP upstream, they would like to have the python2 available for GIMP-2.10 as long as possible. They are already working on GIMP 3 with python3 support, but they haven't set any release date for this version yet.

Comment 8 Petr Viktorin 2019-08-19 12:50:19 UTC
The content of python2-devel will be available (in a different package, python27, but we can help with the transition).

You should check with pygobject2, gtk2, pygtk2 maintainers what the plans are. I've asked them for info here:
pygobject2: https://bugzilla.redhat.com/show_bug.cgi?id=1739544
gtk2: https://bugzilla.redhat.com/show_bug.cgi?id=1737988
pygtk2: https://bugzilla.redhat.com/show_bug.cgi?id=1739543

Some seem to be non-responsive. If you can reach them outside Bugzilla, it would be helpful.

What about pycairo, libglade2, python2-numpy? Does gimp need them, or are they (from your point of view) just implementation details of other packages?

If maintainers of the dependencies are willing to keep the Python 2 parts in Fedora, the next step is filing an FESCo exception. Here's an example: https://pagure.io/fesco/issue/2208

Comment 9 Petr Viktorin 2019-08-19 14:57:32 UTC
It would make sense to include the plugin gimp-layer-via-copy-cut in the FESCo exception, as well.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1738968

Comment 10 Miro Hrončok 2019-09-16 21:53:43 UTC
I've tried to rebuild gimp without pycairo-devel and pygobject2-devel BRs. https://koji.fedoraproject.org/koji/taskinfo?taskID=37693721

It works, however pygtk2-devel brings both of them in.

Comment 11 Miro Hrončok 2019-09-19 12:19:36 UTC
I've noticed that gimp is modularized. Can we just build all the Python 2 dependencies in that module and retire the stack in rawhide?

Comment 12 Miro Hrončok 2019-09-23 22:38:30 UTC
I see two ways to go forward:


Way 1 - FESCo exception for:

 - gimp
 - gimp-layer-via-copy-cut
 - pygobject2
 - pygtk2
 - python2-numpy
 - pycairo (we don't know yet if the maintainers agree to keep the Python 2 subpackages)


Way 2 - put the abovementioned packages to the GIMP module and retire nonmodular GIMP.



It would really made me much more comfortable if we get this sorted out sooner than later. I don't want to retire GIMP in November.

Comment 13 Josef Ridky 2019-09-24 06:34:35 UTC
Hi Miro,

due we shipping GIMP as module already [1] I am fine with the way #2.

Can you help me with necessary steps to make this change as smooth as possible?

[1] https://src.fedoraproject.org/modules/gimp/tree/2.10

Comment 14 Kalev Lember 2019-09-24 06:37:29 UTC
In addition to rpm GIMP, I care about GIMP flatpak that we are already building and shipping in Fedora. The flatpak builds use MBS, so this can use the same solution as #2.

There may be issues building Python 2 with --prefix=/app for flatpak, but if this is the consensus to go forward I'd be happy to submit patches to python2 to help fix that.

Comment 15 Miro Hrončok 2019-09-24 08:51:27 UTC
> Can you help me with necessary steps to make this change as smooth as possible?

I'm not sure, how can I help?

Comment 16 Miro Hrončok 2019-09-24 09:29:48 UTC
I forgot to mention: The Python Maintanence team can help here with way 1 (requesting the exception). We cannot really help with modularizing stuff.

Comment 17 Josef Ridky 2019-09-24 09:33:53 UTC
Due we already have gimp module, I need just someone (form modularity team?) to check, if all dependencies (esp. to python2 module) will be set correctly.

Do you know anyone, who can help me with it?

Comment 18 Miro Hrončok 2019-09-24 09:42:13 UTC
There is no python2 module. I don't know anyone who can help you.

Comment 19 Petr Viktorin 2019-09-24 10:23:45 UTC
> Can you help me with necessary steps to make [modular Gimp] as smooth as possible?

I can think of tho things that will not be smooth:

1. It's possible that we won't remove all dependencies at once. If we, for example, drop python2-numpy in F31, pycairo in F32, and pygtk2 in F33, these will need to be added to the Gimp module. As far as I know, there is no mechanism to check if they will conflict with any other modules, or (if there's a single Gimp stream for all Fedoras), with non-modular RPMs in older Fedora releases. And if they do conflict, I don't know what will happen and how things will be coordinated.

2. As a user, when I install Gimp, I get the "2.10" module. As far as I can see, it won't upgrade when 3.0 comes out: if I want that, I'll need to watch for Gimp release and switch streams manually (maybe even uninstall, switch streams, and reinstall). If i stay on 2.10, I don't know what will happen when 2.10 stops being supported.

Unfortunately, as far as I know, Modularity has no good answers to these (future) issues. I don't know what to do to solve them.
I'd be willing to treat these as the cost to pay for things being better in the future. But unfortunately, I don't really see any problem that Modularity solves *for Gimp in Fedora*. I am not aware of any benefit we'd get for enduring the annoyances.


I can help with a FESCo exception (that's mostly a way to ensure everything is coordinated, relevant people are notified and the packages are listed), and I can offer some help with maintaining the dependencies for Gimp until it is ported. But I *don't know* how to do things properly in a module.

Comment 20 Kalev Lember 2019-09-25 06:54:28 UTC
(In reply to Kalev Lember from comment #14)
> In addition to rpm GIMP, I care about GIMP flatpak that we are already
> building and shipping in Fedora. The flatpak builds use MBS, so this can use
> the same solution as #2.
> 
> There may be issues building Python 2 with --prefix=/app for flatpak, but if
> this is the consensus to go forward I'd be happy to submit patches to
> python2 to help fix that.

I've filed https://src.fedoraproject.org/rpms/python2/pull-request/49 to fix an issue with python2 flatpak builds.

Comment 21 Josef Ridky 2019-09-25 13:59:39 UTC
To be honest, now I really don't know, which way I should go.

But due of possible issues in modularity, which aren't solved yet, I would request FESCo exception for GIMP.
It looks like safer way now.

What do you think? Do we have some template for exception request?

Comment 22 Miro Hrončok 2019-09-25 14:21:59 UTC
Before we proceed, Kalev, you are the main admin of pycairo. Would you be OK to keep Python 2 bits of pycairo around until GIMP is ported to Python 3?

Comment 23 Kalev Lember 2019-09-25 14:23:23 UTC
Yes, I would be OK with that.

Comment 24 Miro Hrončok 2019-09-25 14:32:07 UTC
I'm now checking whether we can remove numpy (and setuptools) from the equation: https://src.fedoraproject.org/rpms/pygtk2/pull-request/1

Comment 25 Miro Hrončok 2019-09-25 14:53:23 UTC
(In reply to Miro Hrončok from comment #24)
> I'm now checking whether we can remove numpy (and setuptools) from the
> equation: https://src.fedoraproject.org/rpms/pygtk2/pull-request/1

This is blocked by ~recent pango update.


I propose the following:

We assume numpy si not needed. We only include gimp, gimp-layer-via-copy-cut, pygobject2, pygtk2, and pycairo in the exception request. If we later realize we indeed need to keep numpy, we request additional one for it.


Here is the draft:

"""
Hello, we'd like to request a Python 2 exception for GIMP (gimp + gimp-layer-via-copy-cut packages).

It needs the following Python 2 packages to run and build (apart from the interpreter itself):

 - pygobject2
 - pygtk2
 - pycairo

The maintainers of the 3 packages are ready to keep maintaining the Python 2 parts of their packages as long as GIMP needs them.

We consider GIMP important for Fedora users.

The gimp-layer-via-copy-cut package only uses Python 2 because of GIMP and has no further Python 2 dependencies. There are other `gimp-*` packages out there, but none of them depends on Python directly (only trough GIMP), to clarify, we want to keep them as well.

See the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1737933
"""

WDYT?

Comment 26 Petr Viktorin 2019-09-26 07:04:26 UTC
There is also gimp-resynthesizer. I think it would be good to include it in the exception.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1751502

Comment 27 Josef Ridky 2019-09-26 07:14:15 UTC
Request posted https://pagure.io/fesco/issue/2238

Thanks for help.

Comment 28 Miro Hrončok 2019-09-26 07:25:12 UTC
Oh, I haven't figured out that gimp-resynthesizer is still a thing, It fails to build for more than a year. Sorry about that. I see it is part of the exception request.

Comment 29 Luya Tshimbalanga 2019-09-28 18:27:08 UTC
(In reply to Miro Hrončok from comment #28)
> Oh, I haven't figured out that gimp-resynthesizer is still a thing, It fails
> to build for more than a year. Sorry about that. I see it is part of the
> exception request.

I recently took over gimp-resynthesizer maintenance and updated to the latest upstream release: 
https://bodhi.fedoraproject.org/updates/FEDORA-2019-205f6d17d6

Blocker added to keep track of this report.

Comment 30 Luya Tshimbalanga 2019-09-28 18:34:42 UTC
(In reply to Kalev Lember from comment #14)
> In addition to rpm GIMP, I care about GIMP flatpak that we are already
> building and shipping in Fedora. The flatpak builds use MBS, so this can use
> the same solution as #2.
> 
> There may be issues building Python 2 with --prefix=/app for flatpak, but if
> this is the consensus to go forward I'd be happy to submit patches to
> python2 to help fix that.

Speaking about gimp, is there a documentation guideline to effectively prepare a flatpak version of addons? I am aware flatpak getdit did before.
Wearing my design suite lab maintainer hat, I am aiming to use Fedora Silverblue as a base system.

Comment 31 Kalev Lember 2019-09-29 14:24:38 UTC
(In reply to Luya Tshimbalanga from comment #30)
> Speaking about gimp, is there a documentation guideline to effectively
> prepare a flatpak version of addons?

As far as I now, fedora flatpak infra does not support app extensions yet. A way to work this around would be to just package the plugins in the same flatpak together with the main app. Is there something specific you need?

Comment 32 Luya Tshimbalanga 2019-10-03 17:00:38 UTC
(In reply to Kalev Lember from comment #31)
> (In reply to Luya Tshimbalanga from comment #30)
> > Speaking about gimp, is there a documentation guideline to effectively
> > prepare a flatpak version of addons?
> 
> As far as I now, fedora flatpak infra does not support app extensions yet. A
> way to work this around would be to just package the plugins in the same
> flatpak together with the main app. Is there something specific you need?

Just a guideline for that workaround. Otherwise I will wait for the Fedora Flatpak infra to enable support of app extensions.


Note You need to log in before you can comment on or make changes to this bug.