Interest to create Flatpak for 3D Slicer, have issue with GUISupportQtOpenGL not found

Support
41

@ruffsl you can find the generator and the flatpak repo here:

I would be surprised if these work nowadays, but can be used for learning some useful patterns.

If you are thinking of NixOS, you may want to have a look at a GNU Guix environment definition that I played with not long ago ( Slicer/.guix/modules/slicer.scm at guix-5.8 · RafaelPalomar/Slicer · GitHub ). Be aware that the branch contains not only the Guix environment, but also Slicer changes needed to accommodate the offline build (see the latest commits I made in the history).

Another initiative you may want to have a look is the SystoleOS. The vision of this project is to package 3D Slicer in modules, together with an ecosystem of packages (PlusToolkit, etc.) to help developers building medical devices. We had an initial experience with GNU Gentoo, which can be found in the gentoo-overlay repository, but conciliating different software stacks with common dependencies (in different versions) made it difficult to maintain. These days we are working on the guix-systole channel, which removes some of the problems we had with Gentoo. This is a not (yet) funded project and has limited functionality as of today, but it is moving forward.

Yes, 3D Slicer is actively being developed, sometimes changes in the core or the building infrastructure breaks API/ABI. A matching revision between 3D Slicer and the extensions distributed guarantees compatibility. However, a matching revision does not guarantee that 3D Slicer built in one environment (e.g., Flatpak SDKs) will be compatible with Extensions binaries built by the 3D Slicer build servers.

As much as I love the idea of a packaged Slicer on Nix, Guix or Flatpak, at the end of the day, it does not solve any problem. 3D Slicer is already largely compatible with many GNU/Linux distributions and it is already compatible with MacOS without the need for its users to install the Nix package manager. Rather than Slicer developer chasing dependencies on Nix or Flatpak SDKs, communities in those spaces should maintain the package(s).

From the 3D Slicer perspective, I think there are legit cases for (1) enabling python packages to be installed in user space (containers, SystoleOS, Nix/Guix, etc. could benefit from it), (2) better decoupling of the extension manager (while there are options to disable a build with the extension manager, some minor changes are needed to honor this option). These changes, in my view, are independent, concise and can help communities to get close to their own packaged Slicer.