As long as you keep the build process simple for people to test, build, and install like it is now, I'm sure we'll be fine with whatever you decide to change it to. That's another part of why MyPaint has been easy to distribute. If you do make changes, I'll make sure it builds on Arch via the AUR since that is my dev platform.

My only request is don't make it rely only on pip, it needs to rely on the system packages.

edited: Clarify my goals with building MyPaint.

Any modernised build pipeline should follow a similar process, i.e. install build dependencies, run a build command (albeit with different tooling), and prepare build artefacts for distribution as you do.

I'd like you to elaborate on pip and the concept of being "self-contained", though.

Wouldn't it be the case that a (theoretical) build process with more parts in a python venv with locally installed pip modules is more self contained than installing python packages on the OS package manager?

I'm not sure if this is possible, though, as the current build process relies heavily on system-level development tools like gtk's development headers.

Since we actually use many non-Python dependencies, I wonder if we should not just switch to a general-purpose build system.

Meson is quite popular with GTK apps and supports building subprojects for easy builds on platforms without package managers. I am adding it to libmypaint in mypaint/libmypaint#193

Some examples:

• https://github.com/jtojnar/nonemast: meson only
• https://github.com/CleoMenezesJr/escambo: meson only
• https://github.com/kra-mo/cartridges: meson only
• https://gitlab.gnome.org/GNOME/pygobject: meson + pyproject.toml (meson-python
• https://gitlab.gnome.org/GNOME/gi-docgen: meson + pyproject.toml (Poetry ¿for dependencies? but really setuptools) + setup.cfg (setuptools)

I'll do some reading on Meson. I'm fairly new to python development so I'll first need to spend a couple days reading up on setuptools and understand MyPaint's build process.

I'm all for Meson as well for building MyPaint and Libmypaint too. @jtojnar Since you were doing a PR for switching libmypaint to Meson, could you submit a PR for MyPaint as well? I'll make sure to pull that in as a feature branch and add you to the dev team so you and @AesaraB further develop it. The same goes for libmypaint too.

I'm going to work on switching MyPaint to Meson, if Jan wouldn't prefer to do so themself. Actually, I'd like to know where Jan sees themself in the project, so I know where I should stand in relation to them.

If you are able to port it to Meson, feel free. I only have access to a crappy laptop during the week so probably will not be able to work on it for a while.

I can help with some reviews (GTK/GNOME platform, Meson, CI, Nix…) and some clean-ups/porting to newer libraries (I do that pretty often when trying to improve the ecosystem as a NixOS package maintainer) but I likely would not be able to find the capacity to work on features and other non-janitorial developments.

Also, the purpose of managed_install/uninstall is a full install command in a Linux environment. It was mainly there for testing changes on Main without having to use Arch or manually build it. It is destructive cause it doesn't inform the OS or use a package manager and the files are only tracked by a file generated by the command. We could probably live without it, but it is a handy tool. It is there for people like me for the most part.

The equivalent is that like make install but can be undone.

managed_installed is meson's equivalent to meson install. It will be included in the new build system.

The current plan for the build system is to incorporate:

• meson compile -- prepare C/C++ and python files for install or distribution
• meson dist -- Create a release archive
• meson install -- Useful for using MyPaint built locally and for developers.
• meson test -- Run unit testing/static analysis

Can you run me down which setup.py functionality you would want?

Setup.py provided these additional commands we used.

• Clean - This removes all build bits and resets the repository to what it was before the build state.

• demo - quick build and run from within the repository. In testing it's just used to make sure it fully launches. It also handy to quickly test changes before deployment.

• uninstall - this was a custom bit that removed installed components from the system. It's used for custom Linux installs and doesn't rely on the package manager. We like having that when we used scons and made sure it was there with setup.py too.

So what you have right now plus these should address everything I would need.

• clean - shouldn't need to exist as meson does out of source builds. For command meson compile $BUILDDIR the command used in place of setup.py clean would be rm -rf $BUILDDIR

• demo - I'll have to look into it, technically it's a combination of setup.py build, setup.py managed_install (to a temp directory), the command /PATH/TO/mypaint, and trap the temp directory for removal on program exit.

• uninstall - I think this is useful functionality, although it's probably going to be one of the last things I implement.

• demo - quick build and run from within the repository. In testing it's just used to make sure it fully launches. It also handy to quickly test changes before deployment.

Seems like the equivalent of meson devenv.

Seems like the equivalent of meson devenv.

Sounds like it

If it is that easy to remove with clean, then I'll just add that to the build script instead.

With uninstall on setup.py it just kept track of where each file went and dumped it in a txt file. Then the txt file was used for rm to reference I believe.

Meson supports uninstall target (can be run with ninja -C _build/ uninstall) but it will not be able to undo changes done by install scripts.