Migrate to pipenv (or similar tool)

[liberforce]

Right now, pip is used, but it has some drawback. Pip doesn't freeze the exact version of packages used, nor checksum.

Pipenv, while not perfect, allows one to have reproducible installs, which is priceless when you want to understand what has changed and why your tests started failing. This helps reproducing bugs with an exact setup.

The pros:

• pipenv allows exact installation reproducibility (with versions and checksums)
• automatically handles virtual environments, so you can easily run your app with with controled dependencies
• makes it clear which dependencies are for development and which for runtime

The cons are:

• pipenv dependency resolution is slower
• it can't currently update one dependency at a time: you update all or nothing

[diegogangl]

@leio Is this ticket still relevant now that we are on Meson?

[nekohayo]

New efforts going on related to #399 :

• 992

• 999

• 1036

[picsel2]

I've never really used it but it looks like something that uses the pyproject.toml standard(s) is "the cool kid" now. The one modern package manager that I know is poetry.

There is the package meson-python which should be able to connect the python ecosystem with meson.

[johannesjh]

Hi there, I thought I could share my related experience, specifically in the context of building favagtk, which also uses python, meson and flatpak for building and packaging a GTK app. About 1-2 years ago, I found myself in a similar situation: I also needed to somehow integrate flatpak (because that's how most gnome apps are distributed) with meson build (because that's what most gnome apps are built with) with python package management tools such as poetry or pipenv (because I wanted frozen dependencies).

• I could not find a solution that works "out of the box" in an easy, integrated way... I'd be interested to know if such a solution existed.
• I temporarily used flatpak-pip-generator as recommended in the flatpak python packaging tutorial. This initially worked ok, but I encountered problems. My experience was: Running flatpak-pip-generator takes a long time because it downloads package files from pypi before creating the flatpak build module. And I encountered build failures because flatpak-pip-generator tries to build dependencies from source instead of using pre-built wheels, which meant I had to specify a bunch of C/C++ compile-time dependencies in order to get a working build process.
• I then wrote req2flatpak as a replacement for flatpak-pip-generator, and that is what I am using now, in a workflow like this: I resolve and freeze python dependencies using the good old pip-compile command from pip-tools, taking into account what packages come pre-installed in org.gnome.Platform. Poetry or pipenv could be used for the same purpose. I then convert the frozen requirements.txt file into a flatpak build module using the req2flatpak script. This works much faster than flatpak-pip-generator, and it uses pre-built wheels instead of building from source packages, which means the flatpak build is also much faster. The entire thing can be seen in favagtk's requirements folder.

I hope this is of interest for you... and I am interested to see what will be used for GTG.