I support the idea, but I am afraid tar ball will be the main deployment technique for many of our customers, especially internal ones.

I support the idea, but I am afraid tar ball will be the main deployment technique for many of our customers, especially internal ones.

The main problem with tar balls (in my opinion) that we have to deliver them to every operating system and architecture we plan to support. As far as I see even our internal customers use operating systems which are supported by snap. Is there no way for them to use snap?

Every platform: Last time I created tarball for SUSE 11.4 which runs perfectly on all Ubuntu distros (likely all 64 bit Linux platforms younger than 8 years). All dependences carried by the tarball except Linux base.

Typical customer who wants to try out CodeCompass has no sudo right. Can we use snap package in that situation?

Meanwhile I strongly support the idea of a CodeCompass package. That is the "right" solution, and likely the one we suggest to use in "official" installations. But we also have to do a "-devel" package too.

Typical customer who wants to try out CodeCompass has no sudo right. Can we use snap package in that situation?

I don't think so. I get your point then.

I am against snap as having to use snaps involve installing an additional daemon in the system, having to have enough available loop devices in the kernel (so that the snap images and their dependencies are mounted). In addition, snaps had been criticised for creating and sh*tting into a ~/snap directory. (I'm not sure where I stand with this criticism, but the fact is that even user-specific configuration for snaps are not stored in standard and well-known Unix locations such as ~/.config and such.)

If we do want a binary image, however, I do suggest AppImage.

While AppImage also does not work if the system does not support FUSE, FUSE has been enabled in Linux system longer than snapd was a thing. AppImage does not use loop devices, but rather mounts the contents (through FUSE) into a temporary directory, in which a pseudoroot file system is present and starts from there.
In addition, if FUSE exists and enabled in the kernel, and if the user is allowed to use it (in general, it's highly unlikely that someone will not, unless we are talking of Department of Homeland Security grade stuff..., while lack of sudo privileges is much more common), running the AppImage is simply a curl; chmod +x; ./foo as no system-specific information is written anywhere.

It is then up to the application where they will persist user-specific data, there is less enforcement of "containerisation" than with snaps.
This is not much of a concern in the case of CodeCompass, we ask database and workspace paths on every invocation anyways.

If you want to try out AppImage, check out OpenShot which distributes a woefully outdated version in the official repository, and a broken version in their PPA, while the appimage worked flawlessly. 😉 I've recently spent more than a week of man-hours creating a ~15 minute conference presentaion with OpenShot, using their AppImage binary.

@zporky AppImage is basically a flashy tarball that also "cleans up" after itself (there isn't really anything to clean up, as the mount point of the temporary directory is essentially a FUSE-wrapped view into the original binary that is being run... It is similar to, but less destructive than loop devices. In addition, you do not need an actual file system or necessary drivers to a pseudo-filesystem, as the FUSE library baked into the binary release is the filesystem itself.), and the user cannot mess it up by accidentally sudo untaring it systemwide. 😀

The selection of the most fitting package manager system is open for discussion, I will make the title of this issue more broader about that.

A remark @whisperity: snap is bundled e.g. into Ubuntu already (which is the officially supported OS for now), so in this case you don't have to install an extra daemon, it is already present on the operating system. Also I don't think that whether the usage of the ~/.snap folder is conventional or not is of much concern for us. This is a very minor thing.
On the other hand if AppImage does not require sudo privilege, that is a major benefit of course.

I do not recall having snap ever on my system(s). But I might have been too quick to immediately get rid of it post-installation.

Two other key points: while we say Ubuntu is supported to the open-source community, corporate users rarely have Ubuntu (as plain as you'd get it off the shelf as a private person) running on their systems. It's one thing if Ubuntu is forked and "specialised", but Ubuntu is not a "megacorporate" system and infrastructure, people usually go BSD or RedHat when they are corporations.

AppImages are sold as relatively easy to bake. While there is not a single "store" from where the updates could be pulled, if you check out OpenShot, their releases are uploaded as AppImage to GitHub, so we could get Travis to do the same.

Then again, that would imply we have releases... which is now a managerial question, not a technical one.

It may sound dumb but I think that snap would be a better solution simply because it is more popular. More people are familiar with it's usage and they are more likely to look up CodeCompass there. Also the Ubuntu store does contain snaps, so through that CodeCompass could be installed ridiculously easily. Plus the built-in update search in Ubuntu would look up whether we added a new release or not, so once installed CodeCompass could be maintained through a gui.

FYI: Given that we build with CMake and Ubuntu is amongst our supported platforms, we could use CPack to automatically create Debian packages, which contain the instructions to install the appropriate dependencies. I've been toying with CPack recently and Contour is using that in the CI to create per-push packages for bleeding edge users.

We'd need to pin down a few administrative values like maintainer and package group like which one of the big categories it should belong to.

(If we have a CI for Ubuntu 18 and 20 separately, we can configure it to create separate images.)