Release VisiCut as AppImage for Linux

[TheAssassin]

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally sign your AppImages (inside the file) using gpg2
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

[t-oster]

Feel free to provide a build script, preferably dockerized

[TheAssassin]

Dockerizing this shouldn't be a big deal. The biggest problem will be to bundle everything for Java 11. I can just put it in distribute/linux, I guess?

[t-oster]

Yes. If the docker file downloads everything we don't need to bloat the repo with Java binaries etc

[TheAssassin]

Mission accomplished, just have to test the result on a few different distros. I've used appimagecraft to eliminate most boilerplate code. Unfortunately the existing Makefile stuff in this repo doesn't seem to be able to build out-of-source, but we can optimize that later.

I intend to bundle Inkscape and VisiCut together with our laser configs in a single AppImage that is then distributed on all our workstations (as well as visitors' computers). Bundling VisiCut was amazingly simple, since you provide those SNAPSHOT JARs which are mostly self-contained.

The AppImage has a size of 61M, but I think we can optimize that later on.

I'm preparing the Docker stuff and will send a PR asap.

[TheAssassin]

@t-oster what's the current state of this? All the prerequisites have been merged, including a Dockerized build setup. https://github.com/t-oster/VisiCut/pull/657 fixes the setup. Does anything block you from providing AppImages?

The reason I'm asking is I saw https://github.com/t-oster/VisiCut/releases/tag/1.9-71, which didn't provide one although the tools had been merged.

Edit: since there has not been a release in two years, would you be interested in providing AppImages in a continous release for every commit made to the main branch? This is what most AppImage'd software does, e.g., to allow testers to test the latest code, or generally just provide cutting edge binaries. This can be fully automated with GitHub's actions.

[t-oster]

Hi, our goal is to always release the master-branch. I have to look into GitHub actions, since I am only familiar with Gitlab CI. The main problem is my limited time, so I am not sure when I will have time for this.

[mgmax]

IMHO the whole build infrastructure (separate visicutbuilder repository, partly duplicate logic, downloads on https://download.visicut.org ) would profit from some modernization. So @TheAssassin any help is appreciated.

[mgmax]

As far as I understand, the current AppImage code uses its own packaging, and does not include all files provided by the distribute script. To copy an older comment from another issue:

The appimage should include all files included in the "platform independent zip" built by distribute.sh, as otherwise some functionality will be broken (e.g., installing the inkscape extension, default example settings). Preferably, use the zip file as input so that we don't have to duplicate the logic. (The "interface" of distribute.sh may be problematic, feel free to change this to commandline arguments, with a fallback to querying interactively if nothing is specified. We then need to update VisiCutBuilder to use the new interface; I can help with that.)

[t-oster]

Yes. I think everything should be in this project (except for LibLaserCut, which should get a CI that pushes it to maven central). We could use this as a starting point https://github.com/marvinpinto/action-automatic-releases so that every commit to master will create a pre-release on github. Or if we would migrate to gitlab, I could adapt some existing CI scripts I have for other projects.

[TheAssassin]

The "create release on GitHub" part can be handled by pyuploadtool, too, which I maintain and use in many repositories. I think that's the least issue.

I've had a glance at VisicutBuilder. I also think this just adds complexity for this small project. The build infra should be moved over here into this repository. The available code isn't great, but as long as it works (meaning we don't have to spend too much time on debugging), we can easily improve on that. My time is very limited, too, so I can't handle this for all platforms. I'll try to get around moving the platform independent stuff as well as implement AppImage builds. I have quite some experience with CI in general as well as GitHub's actions.

My philosophy for CI related scripts is that you need to have as much code as possible be "CI platform independent", and just write as much "glue" as necessary (i.e., GitLab CI YAML code, GitHub actions workflows etc.) to run the build process. Building from Docker is already nice to have, it'll make things easier.

If someone can take over optimizing and finalizing the macOS/Windows stuff once some basic CI structure is available to run builds on GitHub actions, then I think it'll be best to settle on that CI system for the future.

We should create a separate issue for the general CI move.

[mgmax]

@TheAssassin We already have (almost?) everything here in this repo, you can use distribute.sh to build all packages. Currently the script is interactive (or needs workarounds); we should fix that and offer a non-interactive version.

In the future I imagine the following:

• Logic from VisicutBuilder is moved to distribute.sh as far as possible
• The CI just calls distribute.sh (at least for everything except AppImage)
• The AppImage build also uses distribute.sh and just repackages the "platform-independent ZIP". Currently the AppImage is not fully in sync with the other distribution formats, which leads to bugs. It should use the same JDK version as for Windows, the same starter script as for Linux (respect RAM limits, pass on arguments), ship the same files, ...

Feel free to help towards that.