Thank you very much for the information. And it is a problem of modern software to have dependencies in so many projects, especially if there is a different version per linux distribution.
To be able to maintain it, I think I would have to be a direct participant of the Slicer.org project because now the Flatpak platform or at least the flathub.org repository allows only to publish the packaged application for the authors of the original software.
Nevertheless, I think it would be an important step forward to continue with the task of transporting it to a framework such as flatpak to facilitate access to different users for this application.
While having a stable flatpak makes sense, there is no point for preview versions, which change nightly. The other issue, is it even possible to install Slicer in a single read/only location (e.g., /usr/local/Slicer) and have the user files (extensions, pip packages) etc go in a local folder?
I would like to see this happening and I definitely could contribute to this. I’m not acquainted with Flatkpaks, but in general terms, there are two issues that complicate the integration of 3D Slicer with package systems:
One of the issues (as pointed out earlier in the thread and in the reference provided by @jamesobutler) is the superbuild approach, as many packaging systems require network isolation. In the SystoleOS project, we have the same issue and have been advancing on building 3D Slicer without the superbuild (so far, Slicer without python support is available). I hope for further advances during PW38.
Another issue is the divergence of some of the underlying dependencies from the official projects (most notably VTK, and to a minor degree, ITK). This makes difficult the co-existence of Slicer and other projects without some isolation mechanisms.
It may be possible to hack our way through (i.e., repo injection, etc) to make a Flatpack with the superbuild (@jcfr posted some snippets earlier in this thread). In my view, it would be better to invest some effort to make 3D Slicer possible to build without the superbuild as this will improve the overall quality of the 3D Slicer project and facilitate other packaging approaches beyond Flatpak and GNU/Linux systems.
There is not much progress since last time because Slicer relies on super build. I think when Slicer can build without network, it would be much easier to build and maintain Slicer flatpak.
Hi Andy,
I would like to be able to package Slicer inside with flatpak. Could you share the progress you made or comment on how far you got to go from there?
Thanks a lot
@Andythe_great, @luarpy we celebrated PW38 last week and we got good progress in the SystoleOS project. Most of this progress can be utilized for breaking the superbuild. I could support this initiative by transferring this and any future progress in the SystoleOS (and more, if needed).
I have been thinking about how we might approach this case. It seems to me that while we try to solve the superbuild issue in Slicer, which doesn’t work, we could adapt the configuration files and download the dependencies through several scripts launched from a main one.
This way we do not force changes in the original project files and make only the right changes for this particular case. The changes should be no more than indicating where the dependencies are located with respect to the packaging path.
Then we would only have to apply the packaging via flatpak and everything should be fine (I’m sure bugs will come up during the process).
I have created this repo and given @luarpy full access
As there are still some uncertainties related to the development and the maintenance of this project I think it is prudent to have it as a separate project. We can discuss with the Slicer core developers if at some point this could be integrated in the Slicer organization. @pieper, @lassoan, @jcfr, do you think this is a good plan?
As will be seen, bundled dependencies can be automatically
downloaded as part of the build process. It is also possible
to apply patches and perform other transformations.
Having bundled dependencies directly linked to the repositories used by the Slicer superbuild and the SystoleOS patches available in the SystoleOS/gentoo-overlay repository is one possibility. In the SystoleOS project we are trying to contribute all these patches to 3D Slicer, but some of them might take time and some others might not even be accepted.
Yesterday I was preparing some of the main files: manifest.yaml (also the one made by @Andythe_great), icon image and *.destkop file. All according to flatpak format. So I can do a push to start with something.
I also have a script I was preparing to automate the configuration process prior to packaging.
On the subject of what you indicate, I also read it but I did not understand how or what is meant by these libraries. I would have liked to find an example showing how to indicate the libraries to download.
Here is a ChatGPT-generated manifest bundling an ITK and a VTK. Does it look plausible? Keep in mind that we need to use Slicer/VTK and Slicer/ITK instead of vanilla ITK and VTK:
Getting this to work would be a good starting point. I hope we can rely on the stock Flatpak runtime system for everything below VTK. This is de dependency graph for Slicer on SystoleOS (no python support yet):
It is the most unexpected answer possible hahahahahaha . It seems to be fine but needs some changes. I wrote it in YAML because it allows to add comments to the document.
This is what I wrote based in the documentation of flatpak and using the Weasis Flatpak project as an example:
A good mix of the two is a good start. Would you mind to make it a PR so I can give it a shot? As I see the problem now we can go a long way by translating the SystoleOS packages to this yaml representation.
UPDATE: Based on the discussion held on 2023.02.07 Weekly Meeting with the Slicer core devs, it seems reasonable to try approaching the Slicer flatpak under a superbuild approach rather than a non-superbuild as I initially proposed. Reasons: (1) some of the SystoleOS patches may take time to land on the Slicer code base, some might not even make it; (2) the distributed Slicer should be the same (or very similar) regardless of whether this is a flatpak or a redistributable linux binary, as of today this a superbuild-based.
It is great to see all the progress with the build. I can help with runtime questions. More specifically: what folders can be read-only and what temporary and persistent writable folders we need for application settings, extensions, Python packages, DICOM database, cached downloads, etc.
I leave two interesting pieces of information I found recently:
I don’t think it would affect this development, but Ubuntu is planning to drop Flatpak integration by default (users will still be able to install the support manually as it is for many other distributions). More information on this post:
Also found an interesting FOSDEM 2023 talk about Flatpaks, Snaps and AppImages from an OpenSUSE developer:
AppImages: “fail in everything they set out to do” → Don’t use them.
Linux apps running everywhere → They don’t
Easy to install apps as in Windows or Mac → They are not.
Provide applications without the need to ‘get into a distribution’ or ‘build for a different distributions’ → Practically, you need to learn every distro and build one.
Snaps → Practically confined to Canonical ecosystems.
Still very limited to Ubuntu ecosystem (won’t deliver confinement in most Linux distributions).
Very dependent of Canonical. There is a pricing model for serious delivery of apps and there is no open-source delivery option (open format, but not open delivery).
Flatpak → The only option ready for primetime
Reasonable isolation model. The client is easy to integrate in any Linux distribution
Translates licensing and dependencies freedom and responsibility to the packagers
. It seems to be fine but needs some changes. I wrote it in YAML because it allows to add comments to the document.