In order to have a better packaging for LAMMPS-GUI on Linux, I am experimenting with creating a flatpak package. Below is a link to download the current version. If you are using flatpak (or curious about trying it out), please try this version and report any misbehavior or crashes.
to install run: flatpak install --user lammps-gui-1.6.6.flatpak
to run type: flatpak run org.lammps.lammps-gui
also check the applications menu of your desktop environment. LAMMPS-GUI should show up under “Science”
[Update]
Forgot to mention. After installing the flatpak bundle you can also run the console LAMMPS executable with e.g.: flatpak run --command=lmp org.lammps.lammps-gui -in in.lj. Same goes for other included executables like msi2lmp or chain.x or phana.
[/Update]
Does anybody here have any opinion about dropping the .tar.gz archives with pre-compiled binaries for Linux and only providing flatpak bundles?
How common is using flatpak?
How much would people be opposed to having to install flatpak support? Especially, for people using Ubuntu, which has its own app-bundle format.
I am not the bigger LAMMPS-GUI user but I think it would be good to drop the archive to go for a pre-compiled binary for the dissemination of the GUI.
However, I think the choice of the format is a tricky question as there is currently a ongoing competition between self-contained packaging formats among the Linux distributions/communities (this is not even mentioning people against such packaging practices). Flatpak is pre-installed in most Red Hat derived distribution but Ubuntu derivatives are most likely to be bundled with Snap. It is possible to install Flatpak on Ubuntu but I don’t think this would be worth it for a single program. Same goes for Fedora and Red Hat with Snap. Also consider that many users have their computer controlled in part by their IT department (and that not everyone negotiate with them to get root privilege, or even know how to install/compile programs as a simple user).
Flatpak and Snaps being the most used modern self-contained packaging formats, what do you think about making both? Would this be too much work to maintain? In any case I think the flatpak format is the best choice since the institutional and scientific linux communities have been essentially using RH/CentOS and its derivative for a long time. I think the switch to Rocky Linux for people deceived bu the CentOS Stream announcement is slow but will take place. It is more likely than a switch to Ubuntu.
Personally, I am against it. The beauty of pre-compiled binaries is that they just work™. You don’t need any other software to run LAMMPS (except tar), especially the root access is not required. Meanwhile, with Snap/Flatpak you need to install the underlying infrastructure and AFAIK it is impossible without sudo.
Actually, I plan to use LAMMPS-GUI for teaching students in the upcoming semester and switching from precompiled binaries to Flatpak would make it more difficult, because I would need to ask the administrators to install flatpak itself on the faculty computers. I am not saying it is impossible, but it adds another layer of complexity without any real gain for the users.
@mkanski Thanks for sharing your perspective. This is very valuable. I wish more people had the time or courage(?) to respond since as a developer you are often very disconnected from how the user of a software actually thinks about it.
Unfortunately, that is not always the case. The Linux distribution that I am compiling them on has to at least as old (i.e. GCC and GLIBC and other core libraries) as the one you are running on. Right now, I am using an Ubuntu 20.04LTS virtual machine, for which the OS support has ended this year, so I should be switching to 22.04LTS at some point. Ubuntu 20.04LTS puts some constraints on the Qt functionality available, since it uses version 5.12 which is lacking some functionality compared to Qt 5.15LTS and Qt 6.6LTS which are the Qt versions that I am targeting. Originally, it was only Qt 5.15LTS, but my Qt skills have improved a bit since I started the project.
If I ever get around to do a full rewrite to get rid of the hack-upon-hack mess that the code currently is, I would probably consider making it Qt6 only, which would limit how far back in time I can go for building the binaries.
I also noticed that I have to bundle a more recent version of the xdg-open script for very recent distributions, or the QDesktopServices::openUrl() function to get context aware help from the online manual will fail.
So, from the developer perspective, flatpak is preferred, since it provides a consistent runtime, even on older Linux distributions. Also, it is easier to maintain, since it is basically a “remote controlled” installation with CMake. So for as long as “make install” keeps working well eough, it will be usable. I also like the automatic integration into desktop environments. But at the same time, I agree with your concern, that having to have the flatpak infrastructure installed is a major barrier. I have not used any flatpak applications myself, because I didn’t like that I have to keep all that extra data around for the flatpak runtimes (and the fact that there are multiple of those that may be required based on what the applications use).
For the time being, I plan to offer both. In a year or two, I can look at the download numbers and then make a choice, if needed.
The arguments between flatpak and Snap are a minor concern actually compared to the popularity of the “conda” system, which is in essence a user-level package manager but without the sandboxing and thus with a lot of problems. So, if I wanted to take the most popular path, it would have to be a conda repo. Unfortunately, there are too many ways how a conda environment, if not used and maintained very carefully, can mess up people’s software environment. I have seen this far too many times on our local HPC clusters. So I have come to the conclusion that conda often creates more problems than it solves and recommend against it, despite the apparent convenience.
Creating a Snap package is out of the question for multiple reasons: political, practical, and personal. I can elaborate in personal communication, if needed.
I guess most people would just adjust to a new system, so they don’t feel a need to express their point. Probably a simple poll would get more responses.
I guess it almost always work out-of-the-box, provided your system is new enough. (:
I understand that from the programmer’s point of view it’s much more convenient to use flatpak and I’m not entirely against this system, especially in case of some more demanding programs which require specific versions of some libraries.
I think there is also a third option you may be interested in - Appimage. Its major downside is that it has one file - one app policy, so it would be impractical to bundle all the LAMMPS tools. However, for the LAMMPS-GUI itself, it would combine the major advantages of pre-compiled binaries and flatpak - it works out-of-box, without any additional software, and you need to create only a single version for all Linux distros (at least I think it works like that, I only used it from the user side).
I can only agree on your opinion concerning conda. It requires very strict organization of the virtual environments for it to be useful and is very easy to mess up with. I speak from experience…
I also have a lot of issues with the Snap package system so I think I can understand your point already.