jim-easterbrook / Photini

An easy to use digital photograph metadata (Exif, IPTC, XMP) editing application.
https://photini.readthedocs.io/
GNU General Public License v3.0
156 stars 24 forks source link

Photini as AppImage #66

Closed luphord closed 2 years ago

luphord commented 2 years ago

Photini is a great piece of software and I really enjoy using it!

However, installation on various Linux systems is anything but straightforward. This is due to several dependencies and their interactions. Have you considered offering Photini as an AppImage for simple installation?

jim-easterbrook commented 2 years ago

I hadn't considered that. I'm gradually simplifying installation where I can, e.g. using python-exiv2 for metadata access instead of the mess of GObject, GExiv2, Python-GObject and so on. If anyone wants to add Photini to AppImage there's nothing in the licence to stop them.

Note that there is currently no single choice of Qt library that runs on all Linux systems. (Nor on all Windows versions.)

The long term solution would be to get Photini into various Linux systems' package managers. That's out of my hands.

luphord commented 2 years ago

python-exiv2 for metadata access instead of the mess of GObject, GExiv2, Python-GObject and so on

Oh, nice! That should solve an annoying problem I had been facing on Linux Mint (breaking the Pix image manager by installing a dependency for Photini).

Note that there is currently no single choice of Qt library that runs on all Linux systems.

That is the type of problem that AppImage is meant to solve. By bundling all dependencies, the availability of system Qt libraries would not matter anymore.

The long term solution would be to get Photini into various Linux systems' package managers.

Yes, that is the classic way of doing deployments on Linux and it certainly has its merits. If nothing else, it shifts the packaging maintenance burden away from application developers. Personally, I am not so optimistic about this model in the future. I expect an increasing amount of packagings/deployments to come from upstream developers. For server software by means of docker, for desktop software by means of whatever distribution-independent mechanism will gain the most traction.

Anyway, if you do not see AppImage as an option, I am closing this issue. Thanks a lot for getting back to me!

jim-easterbrook commented 2 years ago

You've prompted me to think a bit more about how I usually install Python packages. Up to now I've been a big user of sudo pip3 install ..., which many articles (e.g. https://opensource.com/article/19/4/managing-python-packages) will tell you is a bad idea.

From now on I'm going to leave the system site-packages directory to the system package manager, and use pip3 install --user ... for any packages that aren't available from the system. (Or for packages where a newer version is required than is available from the system.)

If I run into package version conflicts (I haven't yet had this problem) then the package that requires an old version of a dependency will be confined to a virtual env.

I will probably update the Photini installation documentation to follow these rules in a week or two.

luphord commented 2 years ago

I had naively assumed that installing photini dependencies via pip was a non-starter as you did not mention it in the docs. But to my surprise, the following produces a working installation of photini on Linux Mint 20.3:

python3 -m venv photini-venv
. ./photini-venv/bin/activate
pip install PyQt5==5.15.6 PyQtWebEngine==5.15.5 python-exiv2==0.9.0 PyGObject==3.42.0 pyenchant==3.2.2 setuptools==60.9.3 gpxpy==1.5.0 requests-toolbelt==0.9.1 requests-oauthlib==1.3.1 keyring==23.5.0 Photini==2022.1.0

This is already a huge improvement for me as this installation is completely isolated from the system libraries. It works well because there are binary manylinux1 wheels for most of the dependencies on amd64 (x86_64). It probably would not work so well on arm or arm64, e.g. Raspberry Pi. Compiling complex native dependencies usually fails in my experience.

So yes, installing dependencies via pip may actually be a feasible approach for users. I just hope you will not get too many support requests when PyQt compilations fail :wink:

jim-easterbrook commented 2 years ago

PySide & PyQt "binary wheels" are hit & miss in my experience. For example, PySide6 would not run on openSUSE 15.2, despite being a "manylinux" binary wheel that should have been compatible. (PySide6 will also not run on Windows 7.)

A shortcut to install all of Photini's dependencies is pip install --user photini[win7] - this is now the recommended way to install on Windows. Use win10 instead of win7 if you want PySide6 instead of PySide2.

PyEnchant may not pick up the system wide dictionaries if it's installed with pip instead of the system package manager.

jim-easterbrook commented 2 years ago

I've done a major reorganisation of the installation instructions. Use of pip and virtual environments is now encouraged, although I still think the Qt stuff should be installed with the package manager.