gimp-python not available in Ubuntu 20.04

OK, I’m not native, maybe I mess up the wording.
What I mean is that I’d like to be able to keep using GIMP without loss of power or functionality.
I know perfectly well about Python2 (I code in Python). It would be a pity if for this reason GIMP would get worse than it was until now.
Right now, speaking purely as a user, the functionality and the user experience is getting worse, unfortunately, it’s not even staying the same. This is always a negative thing, for any software, from the user point of view.
I needed to come up with workarounds to keep doing what I was doing before. Ideally, a tool should never get worse, at the minimum it should stay the same (also here I don’t know exactly how to express it). Getting better is a plus (optional, let’s say).

Please, note I’m not complaining here, I know fully well how hard it is to keep GIMP as it is, and I’m indefinitely grateful for just having it. But I think it’s fair to say that this situation with Python is really a pity at the moment. GIMP did get worse for me in the past weeks/months. And it does not look brighter in the immediate future (unless I stick to these workarounds).

1 Like

Then don’t upgrade. that’s one of the best things about Free Software, nobody is making you do anything. If you’re happy stay with that version until its feasible to upgrade.

1 Like

I’m fully aware of that :smiley:
It is really good, and I’d setup a VM to run that. But I do want (as I always did) to take advantage of updated distros and software (e.g. for newest lib versions, especially if I have new cameras).
But I’d then have a new distro, that comes with GIMP in it, most likely, but that GIMP will be potentially an inferior version to one I was using before, so I’d have to find some workaround to make it work (e.g. a VM with a different distros).
And yes, I agree, the beauty of FOSS is that it allows for such workarounds. But I still think it’s a pity, whenever a step-back has to be made (independently of the technical reason).

I tried that a couple of days ago after reading that someone else had success going that route, but didn’t have the heal selection option. Maybe I used the wrong release version. I’ll try it again. I like the concept of having some applications all rolled into a single package so that dependencies can all be included and embedded in the “executable” without impacting other applications. Although from a security perspective - it’s a little on the scary side.

[EDIT 4/30/2020 3:24 AM Central]
Eureka!!! That worked! apparently first time I tried it was with 2.10.8 not 2.10.18.

The AppImage for 2.10.18 works just fine! Thanks everyone!

1 Like

It’s actually not that unsafe, your system is not really affected, and you run it as user.
It’s more dangerous to use PPAs (e.g. in Ubuntu), for instance. They do affect your entire system and they can update any lib/package in your system, with privileges.

Since this thread is the top hit for a Google search for the gimp-python problem, I’ll post the solution that I found. Ubuntu 18.10’s gimp-python can be manually downloaded and installed into Ubuntu 20.04. One other completely missing missing package, python-gtk2, also needs downloading. All other dependencies can be installed normally from 20.04. No security problems since it’s all from Ubuntu. No forced installation to ignore missing dependencies. “Heal Selection” works, and unlike the flatpak version, GMIC QT works.


sudo apt install gimp gimp-plugin-registry gimp-gmic
sudo apt install python python-cairo python-gobject-2

sudo dpkg -i python-gtk2_2.24.0-6_amd64.deb
sudo dpkg -i gimp-python_2.10.8-2_amd64.deb
1 Like

Thanks :wink: useful to know.
The security issues may come, not because of the source of the packages, which is trusted, but because those packages won’t receive updates, for instance in case vulnerabilities are found in the future.
And even if they receive updates from Ubuntu, you’ll have to manually download and update again, I think, they won’t be part of the automatic updates with this installation, I’m quite sure.
So, if strict security is to be maintained on the machine, those packages must be tracked by hand.

My workaround, on Majaro, is to use the AppImage from @Carmelo_DrRaw, and it works quite well.
Once I move to Ubuntu 20.04 on my other machine (unless I change distro altogether…) I’ll probably use the same workaround when I need the python plugins.

Mixing packages from different releases of a distribution is absolutely not recommended. It will eventually break.

The AppImage works great!


That is interesting to hear. Currently I’m running Mint 19.3 Cinnamon (Based on Ubuntu 18.04). So I think I’ll face similar issues with regards to Python 2 when it comes to upgrading to a Ubuntu 20.04 based distro. So I think I’ll download the Gimp appimage to save any hassles of missing python2 libs! :slight_smile:


I had to search a bit because this link for the GIMP 2.9.5 Appimage is not working but I finally found the Appimages here


That’s the gimp 2.10.20 appimage with plugins downloaded :slight_smile:

I updated the link to point to the nightly builds repository.


Thanks to everybody involved for pointing out the AppImage solution and providing the corresponding links. This worked for me on Kubuntu 20.04. as it seems that I got running :+1: :smiley:

I switched to Linux only 6 months ago, but I must say that I have had some negative experiences with snap packages yet. In these cases, installing the “real” package via ppa helped a couple of times. So I am a little reluctant and stay prepared for the next problem that will arise out of the AppImage solution. Besides, doesn’t this concept contradicts the modular approach in which single modules and libraries are updated separately/independently?

Regarding the general problem and the related discussion in this thread, I can understand both sides. It is absolutely understandable that Ubuntu dropped python 2 support with 20.04. as back-porting makes the further development harder.

But from the user’s point of view this understanding doesn’t help a bit. Because neither the plugin works, nor is its function added to the main program. In this connection I can understand billznn

Clinging to 18.04 does not seem to be a good solution because “wait till there is a fix” is not an option here as darix pointed out.

So, I traced back the author of to some forum, but his last activity was like 5 years ago. So I highly doubt he will come up with a Python 3 version in the next couple of months, years, … okay, that is FOSS, where contributors disappear or have to reallocate their resources.
Next I tried to port the plugin myself using 2to3 and, but failed as I am only a casual coder.
So now I have an AppImage solution and I do not even know where this comes from and how long this will be maintained.

This is not a complaint but merely my two cents about a rather general problem that imho keeps many people from using Linux/FOSS as it still leaves the taste that this is only for people who really like to tinker with their system.

So now I have an AppImage solution and I do not even know where this comes from and how long this will be maintained.

Always a worry. Even whole linux distros have gone with their owner.
The 'buntu PPA that was a mainstay is stuck on 2.10.14 even with the promise “…as long as I live this PPA will never die and the most recent packages will for ever be.” I hope he is OK and well.

The appimage is very-very good, It is now my main Gimp 2.10.20 installation.

However there are improvements to the flatpak, which you can install via the main download at This does come with Python2 installed.

Some plugins are now provided: BIMP / resynthesizer (+python scripts) / Liquid Rescale / Gmic / Lensfun / Fourier and the Gimp help.

With the Gimp flatpak installed you might do something like
flatpak search org.gimp.GIMP.Plugin
flatpak install flathub org.gimp.GIMP.Plugin.GMic

GURM ? largely replaced by Ofnuts resources manager which is derived from GURM. Look for AddonCollectionManager (2013-05-26)

I have that installed in the appimage, works no problem

The whole set of scripts and CI configurations required for building the AppImage are kept here: GitHub - aferrero2707/gimp-appimage
The good thing is that the AppImage creation does not rely at all on private computers and user resources, and is entirely based on GitHub and TravisCI.

I am currently maintaining the packages and have the plan to keep supporting them for as long as I can. Given that all scripts are public, the work could eventually be taken over by whoever knows some bash programming and is willing to contribute…
There is also some discussion about integrating the AppImage machinery into GIMP’s official build infrastructure, but unfortunately things are progressing quite slowly, and this is entirely my fault… see discussion here: Build on official GIMP infrastructure · Issue #9 · aferrero2707/gimp-appimage · GitHub

First of all, thanks to both of you, rich and Carmelo for the good points, explanations and hints. This really helped me in many ways.

Second, I’d like to clarify that my concern about the origin of the AppImage was not so much about safety but also about sustainability/availability and also about the question who to be grateful to. In that respect, many thanks to you Carmelo for dedicating so much work and time in that matter (I read the thread about integrating the AppImage officially). I see the need of helping hands, but regarding my virtually non-existing bash skills, my hands would probably do more harm than good.

Your posts lead me to the conclusion that using the AppImage is probably the best way for me. Thanks also for pointing me in the direction of Ofnuts’ Gimp Tools. Honestly, I haven’t heard about them yet. But as I do digital art as casually as I code, it is no big surprise to me. In fact I was already hoping that there is some alternative to GURM, so I’ll give this a try.
In this connection I have two questions:

  • In order to get rid of the default brushes, patterns,… is it a proper way to simply delete the path to the /tmp/.mount_GIMP_A0pqhO7/... in GIMP’s preferences?
  • In case I mess up things, how do I restore the original state in the sense of re-install? By deleting /home/user/.config/GIMP-AppImage before starting the AppImage?
1 Like

The Gimp appimage works by unpacking the program files (about half-a-GB / 9500 of them) to a hidden folder in /tmp That is .mount_GIMP_xxxxx\ and the xxxxx changes each time you start the appimage. So the folder path to the standard Gimp resources changes as required. It runs via a script so no use adding the --no-data switch, that gets ignored.

You can delete the path in Preferences → Folders. The setting does carry over. I think the only practical way to thin down a big collection of brushes is by using the filter top of the dock. Unfortunately the filter is still broken for fonts, best way is load and unload fonts with your resources manager GURM or equivalent.

There is another way and I am a bit reluctant to bring it up here. The appimage can be ‘unpacked’ and run from a directory on disk same as any other program. All the files are available. There is a security issue, you have to be happy about running outside of root. I am ok with that but it is up to the user.

You are correct about the ~/.config/GIMP_Appimage folder. Delete that and a new default one is created next time you start the appimage. Just the same as an installed Gimp. Useful to keep. The next time Gimp is updated, download the new appimage, run and it will use the existing settings.

Hello, I don’t understand the security issue. The AppImages I use are downloaded to /home/user/Downloads and I run them from there without any problems. Do I miss something here?

I knew I should not have posted that. :slightly_smiling_face: Nothing for you to worry about.

The appimages you use are stored in your home partition but when they run they unpack to Root and run from there.

Erm, you said the appimage unpacks to /tmp. That directory is normally writable for everyone, not just root (with some special settings to limit security issues).

The unpacking shouldn’t require root privileges, and neither should the actual running of the program from the appimage, any more than running a normal install would need root privileges. Installing from a traditional repository requires root privileges, but that’s a completely different story (it needs write access to /usr).