Open ximion opened 2 years ago
Rebased on the current main branch. I threw the Flatpak Action into the "enabled" GitHub Action for now, as that makes testing easier (later those two files should obviously be merged and be enabled or disabled together, not separately)
Wow @ximion, thank you so much for working on this! I will go over this with @hinerm this week.
Sorry I haven't had time to review this yet. It's on my list for tomorrow April 13th. In the meantime, with imagej/imagej.github.io@8bf2e5b3467145093d7a9379fd3dca3915a41b71 I have updated the Fiji Downloads page page to mention this work, since I agree that containerized solutions like Flatpak and Snap are a better fit for Fiji these days.
I'm just gonna say that I tested this by following the above instructions on Ubuntu 20.04 and it seems to work perfectly so far.
Sorry I haven't had time to review this yet. It's on my list for ~tomorrow~ April 13th. In the meantime, with imagej/imagej.github.io@8bf2e5b I have updated the Fiji Downloads page page to mention this work, since I agree that containerized solutions like Flatpak and Snap are a better fit for Fiji these days.
Awesome, thank you! I could also submit this to Flathub, however I am not sure whether this particular package would be welcomed, because we not only not properly build all code from scratch (Maven is downloading a lot of prebuilt components) but also don't have any separation between parts of Fiji and plugins, so the Flatpak has to copy all executable files to a mutable volume in the user's home directory because any one of them might be modified by new plugins or updated by Fiji's updater. That's pretty problematic. At the same time though, a thing like Steam is allowed, and the Steam Flatpak is handling this only slightly better, so Fiji might actually be fine if I polish the code a little ;-)
Sorry again for the slow review and merge on this. Had crunch time for the I2K conference, and now at another conference, so my normal PR reviewing schedule was thrown off. But I just wanted to say again that I'm enthusiastic. I will shoot to review this during my next PR day on Wednesday, May 18.
we not only not properly build all code from scratch (Maven is downloading a lot of prebuilt components)
And I can't resist the opportunity to rant here about packaging systems that want to rebuild Java code. The entire point of Java is "write ONCE" so downloading prebuilt binaries is exactly fine and correct, unlike with native code... 😞
And I can't resist the opportunity to rant here about packaging systems that want to rebuild Java code. The entire point of Java is "write ONCE" so downloading prebuilt binaries is exactly fine and correct, unlike with native code... disappointed
You often do want to verify though that the shipped code you have yields exactly the binaries you want, and that the code to generate said binaries is fully available in the first place (in case you want to modify it). The best way to ensure that is to build things from scratch. You may also want to build it against newer Java versions, different JVM or do who-knows-what for a custom build. Personally I'd like a toggle to enable or disable downloading of binary components, but in any case for this packaging effort here it doesn't really matter all that much - Flatpak just runs the result, no matter how it was built. :-)
I started looking at this today! But got distracted by the ImageJ Launcher patch. The good news is, that PR imagej/imagej-launcher#85 is now merged; the bad news is, the CI never got fully migrated to GitHub Actions after Travis stopped working, so I still need to complete that migration. But I'll punt on it for the moment in favor of testing and merging this PR here, since the patch is also applied manually when building the Flatpak package. I have some conflicts though for the rest of the day, so probably won't finish the review today. Will keep y'all updated.
Since this is linked on the Fiji download page, and since the patch needs rebasing and probably an update as well now, I created a pre-built bundle for people who navigate here and just want to give the easy Fiji installation a try. For most users it should just require downloading the Flatpak file from https://github.com/ximion/fiji-builds/releases/tag/x-test and installing it with their graphical software center.
(Fiji Is Just) ImageJ 2.9.0/1.53t; Java 1.8.0_322 [64-bit]; Mac OS X 10.16; 741MB of 4028MB (18%)
java.lang.IllegalArgumentException: (minimum <= value <= maximum) is false
at javax.swing.SpinnerNumberModel.
Hi! I saw your request for a Debian packager on https://imagej.net/software/fiji/downloads - since I am one, I decided to give this a go, but then ultimately ended up creating a Flatpak bundle for Fiji instead, which I think users may be a bit happier with :-) Flatpak is a widely supported bundling system on Linux, which makes it possible to "freeze" and app with its dependencies, to deploy it easily to pretty much any Linux distribution. It's a pretty convenient and widely available way to make software available on Linux nowadays.
I created this recipe so we could use Fiji easily on our more powerful shared servers where people connect to from remote locations (and where having every user download Fiji manually is pretty inconvenient, compared to just selecting it from the menu and it just working).
There is one huge issue with Fiji in a Flatpak currently though: Flatpak apps are run from a read-only filesystem by design, while ImageJ/Fiji was written to modify its own files at runtime with its own updater. Originally I just intended to remove the updater and use Flatpak's own very efficient update mechanism to automatically keep Fiji up-to-date. Unfortunately, removing the updater also cuts off any way for users to easily install ImageJ plugins, which is not an acceptable compromise. So, what this bundle will do instead is copy the entire Fiji distribution into the user's writable data location and then run it from there. It still runs in the isolated Flatpak environment, but Fiji can modify itself now. Of course this is bad design, as it duplicates data for every user who runs Fiji on the machine, is less secure, and if the home directory is on a filesystem that prevents executables, it won't work either. Ideally, ImageJ/Fiji would be modified to allow loading modules from separate writable paths and to split the externally-managed plugins from the ones Fiji ships with, so one half can be on a read-only filesystem, while users can still add their own plugin sources. But that would require quite a few changes on the existing codebase, so for now the Flatpak bundle uses the copy-everything compromise.
Another pretty evil thing is that network access is enabled during build, but the advantage of that is that the Flatpak bundle can be created very easily using the same process as all the other binary distributions are using.
If you just want a Fiji Flatpak build that you can use on your machine, download a test-build from here: https://github.com/ximion/fiji-builds/releases/tag/x-test
So, how can you create the build yourself?
1. Install Flatpak
2. Configure Flatpak to use Flathub for SDKs/Runtimes
3. Build the bundle
4. Install the application!
You can open the resulting
Fiji.flatpak
in KDE Discover or GNOME Software for a GUI to install it, or install it via the command-line:You can then just launch Fiji by clicking its icon on the menu!
I included changes to the GitHub action with this PR, which makes it build the Flatpak bundle in a separate job and uploads it as an artifact, so you can fetch it from there for testing purposes. I deliberately didn't touch the code that uploads directly to the Fiji download site. This PR will address Fiji issue https://github.com/fiji/fiji/issues/287 Thanks for considering! :-) Cheers, Matthias