Deprecate the snap build

[NobbZ]

With quite some regularity there are issues reported with the snap build.

• It prints instructions to use the opaque and absolute snap path to binary to execute commands. One should never run those directly
• It creates config within the sandbox but searches for them in the user dir when trying to read them
• It It sometimes doesn't seem to have permissions to create the users config in ~/.config

And there have been other weird things reported in the gitter where the student didn't create a bug report here.

No one of the maintainers of the CLI seems able to reproduce the issues, even when using snap on their own.

Therefore my conclusion of this issue is, that the snap-sandbox is also a blackbox for us that introduces unsolvable problems. Since the introduction of the snap, requests for help with installation problems have massively increased in gitter instead of getting less.

The majority of issues are because of snap weirdnesses, and solved by removing the snap replacing it by a manual installation.
Second is beeing confused about the unpack location in a manual installation.
Third is not having installed snap properly before trying to use it to install exercism

(This ranking is based on my personal perceiption and only includes linux derivations)

And even though I still do not like the idea of having a not-managed-by-the-package-manager-program on the computer, I realy think, that creating a simple shell script, which downloads the binary for the current platform, moves it to ~/bin and prints a message that one has to add export PATH=~/bin:"$PATH" to the ~/.bashrc or ~/.zshrc respectively or equivalent commands to equivalent files in any other shell would be the best thing to do.

Students then could install by a curl https://exercism.io/get-exercism | sh or similar.

[gridhead]

And even though I still do not like the idea of having a not-managed-by-the-package-manager-program on the computer, I realy think, that creating a simple shell script, which downloads the binary for the current platform, moves it to ~/bin and prints a message that one has to add export PATH=~/bin:"$PATH" to the ~/.bashrc or ~/.zshrc respectively or equivalent commands to equivalent files in any other shell would be the best thing to do.

Yes, it could get the task done but this kind of installation method might unfortunately not be universal to all distributions out there. There can be certain nuances which could not be sufficiently taken care of during uninstalling a package due to which there can be some residual configurations left back. These can, then, hamper efficacy of other packages which we would not want to make happen, right?

Not using a package manager and providing our own installation method kind of sounds like reinventing the wheel here. 🙂

[NobbZ]

For me installing anything without the package manager of the system is a big no-go (nixos user). More often than not, I can not even run simple scripts from the net without packaging them first.

But the proposed script whould do a "user level" installation of the CLI, not system level. Also the only configuration created by it would be $XDG_CONFIG_HOME/exercism/user.json.

Beyond that there are at most 4 files to install/remove. The binary itself and the completion scripts for each shell.

Last but not least, with the release of v3 in the next couple of months, the CLI becomes optional, and it can be fully advertised as an "advanced" feature. And in my opinion then we can and should also remove those "intendended to make it easier but makes it harder" stuff, and just provide the most basic install instructions:

1. Download
2. unpack
3. copy
4. make sure its in PATH

Users that consider this to be to complicated or don't understand it, can stick to the web UI.

I know that there are also Linux Derivations that are relatively up to date with their provided exercism version. The AUR (Arch) and nixos both are on the most recent versions, and I am responsible to keep the latter updated (within the nixos ecosystem, its not an official thing from exercism point of view).

At the end, I'd fully support prebuild RPMs and DEBs, though I understand the original reason why they have not been provided, while on the other hand side, I think it would be quite easy to provide them for a single binary go program (might be more complicated if we try to also package the shell completion, but AFAIK its also missing in the snap).

[gridhead]

I was trying to volunteer packaging the CLI for RPM based distributions with #987 but now that you said that CLI would be more of a side-thing from v3 onward so I doubt if there would be takers for the packages that I would end up creating.

As far as single binary Go programs go, if the size of the executable is kept down (less than or equal to ~25MB), it is feasible but beyond that downloading, updating and moving around the file becomes cumbersome. One would then want to move the executable to either /bin/ or /usr/bin/ - cleaning up on uninstall still being an issue.

EDIT -

At the end, I'd fully support prebuild RPMs and DEBs, though I understand the original reason why they have not been provided,

Umm... Why aren't they provided?

[NobbZ]

Original reasoning was about differences between different targets for eg. DEB.

Even though if the DEB is pretty standardized, available libraries by default, glibc versions or dependency versions are quite an annoyance and hard to keep track of.

And as no one wanted to build a new DEB for any possible combination of Ubuntu LTS and STS, Debian, and their spin-offs and a similar wild grown eco system on the RPM side, building those packages has been refused.

Though today as talking again about it…

Go binaries are pretty well known to have minimal external dependencies and I am not aware of import "C" in the CLIs code base.

So packaging a DEB/RPM w/o explicit dependencies might already work, as glibc is implied on each system anyway. (MUSL based systems put aside)

[gridhead]

And as no one wanted to build a new DEB for any possible combination of Ubuntu LTS and STS, Debian, and their spin-offs and a similar wild grown eco system on the RPM side, building those packages has been refused.

I don't really know about the DEB side of things but for RPM, I defer. RPM needs the dependencies and the build instructions in a specfile to start with and for Go, there aren't many dependencies to be honest as a compiled binary itself is good to include.

So packaging a DEB/RPM w/o explicit dependencies might already work, as glibc is implied on each system anyway. (MUSL based systems put aside)

Musl is a very difficult nut to crack. I myself have tried and failed to make things work on Alpine unless I have explicitly built on Alpine and for Alpine.

How likely is the CLI to be maintained in the future? This would help me decide if I should to contribute here or not.

[kotp]

Highly likely that the CLI will be maintained. It is the way that we get exercises developed locally, and the exercise downloaded from the platform.

[gridhead]

Highly likely that the CLI will be maintained. It is the way that we get exercises developed locally, and the exercise downloaded from the platform.

So glad to know this, @kotp. I would like to assist with packaging the CLI to RPM based distribution and modernize its LnF.

[kotp]

I have made a little bit of noise for you @t0xic0der

[gridhead]

I have made a little bit of noise for you @t0xic0der

Umm.. I'm not sure I understand what's being conveyed here, @kotp. 😅

[iHiD]

Umm.. I'm not sure I understand what's being conveyed here, @kotp. 😅

@t0xic0der He summoned me :)

---

Some general comments:

• The CI is still considered a "first class citizen" of Exercism, and that won't change.
• However, the editor does mean that people who struggle with the command line don't need to use the CLI, which will reduce some of our pain in support
• I'd like it to be as easy to download/install as possible.
• There has been some discussion of including it as in language-library registries too (e.g. a Ruby Gem, and NPM package, or Julia library. I like the idea in a way, but am concerned about having to maintain a multitude of different deployments.

Some specific thoughts on this:

• The idea of a curl https://exercism.io/get-exercism | sh seems sane to me.
• It would be nice to have RPM packages. The easy of homebrew on mac has shown how well a package manager works for us here.
• Beyond that, I know nothing really about how any of this bit works, so I'll need to be guided by y'all.

[ErikSchierboom]

The CI is still considered a "first class citizen" of Exercism, and that won't change.

Personally, I'd keep on using the CLI for anything but trivial exercises. I assume that this will be true for a large number of people.

I'd like it to be as easy to download/install as possible.

This is also my main point of focus. If we can't get snap stable enough for it to work without putting unnecessary stress on everyone helping out with the CLI, we should consider other package managers instead. Note that I hardly know anything about package managers and how to add a package to them, so I have no idea how hard this would be.

curl https://exercism.io/get-exercism | sh

This would be nice. Could we even get the package manager to use this?

[gridhead]

Some general comments:

• The CI is still considered a "first class citizen" of Exercism, and that won't change.
• However, the editor does mean that people who struggle with the command line don't need to use the CLI, which will reduce some of our pain in support
• I'd like it to be as easy to download/install as possible.
• There has been some discussion of including it as in language-library registries too (e.g. a Ruby Gem, and NPM package, or Julia library. I like the idea in a way, but am concerned about having to maintain a multitude of different deployments.

Glad to know that the CLI is still the primary tool to use the offering at Exercism. The inclusion of a web-editor would, of course, mean added processing requirements at the server end for hosting different environment and I hope that we have enough capital and contributors to pull that off but CLI is ❤️ - easy-to-implement, low risks (due to the fact that using the CLI might end up appearing as a convoluted piece for the inexperienced[1]) and high rewards (for once, it is setup - there's not much load at the server end[2]) in terms of community participation.

Now addressing the [1] and [2] mentioned at the top,

1. It is easy to come across volunteers who could act as support or mentors that to come across those who could help as developers and maintainers. The CLI's apparent learning curve can be reduced by making it visually enticing to be appealing to the inexperienced. Here are some examples I am looking at https://minikube.sigs.k8s.io/images/screenshot.png and https://github.com/t0xic0der/switcheroo. This, of course, is not relevant to the packaging problem and can be discussed about in a separate issue.

2. The CLI is definitely easy-to-use but the issue is understandably in getting it to install on devices first. Albeit, the shellscript works just fine - I'd still suggest using package managers native to the distribution for they are there for a reason. Handling residual configuration files and cleaning up on uninstalling with native package managers like APT and DNF helps keeping the distribution installation sane.

Though I am unable to understand how packaging in language-library registries be achieved, keeping in mind that the CLI is written in Go. We could, of course, consider porting them but then finding maintainer for the ports is a lot of yak-shaving that we would want to avoid here with the use of distribution-specific package manager.

Will be glad to discuss the nuances to be considered in packaging and making the tool friendly to the inexperienced.

This is also my main point of focus. If we can't get snap stable enough for it to work without putting unnecessary stress on everyone helping out with the CLI, we should consider other package managers instead. Note that I hardly know anything about package managers and how to add a package to them, so I have no idea how hard this would be.

Distribution-agnostic package managers like Snap and Flatpak have their own pseudo-containerized environment which might or might not be shared with the configuration directory so it would be very difficult to know the source of the problem due to the complexities introduced by the abstraction of such package managers. Even the shellscript way of installation is much more preferred than using Snap or Flatpak to be honest and we would want to keep things as low-level as possible by using native distribution package managers.

This would be nice. Could we even get the package manager to use this?

A good starting point @ErikSchierboom. This makes me think if I can roll this up in a container and follow the processes done by the shellscript in the RPM spec process. I'll let you know about it.

Have we considered "AppImage" (not that it would be much different from the per-architecture compiled binaries but still something to consider)?

[scmbradley]

Personally, I'd keep on using the CLI for anything but trivial exercises. I assume that this will be true for a large number of people.

Just to weigh in, as a user of exercism, one of the things I really like about exercism (compared to other learn to code/code challenge type products) is precisely that I can easily work on my own setup and get the benefits of the precise set of tools I like, rather than those imposed by some web platform. So I really hope the CLI continues and thrives!

[iHiD]

CLI isn't going anywhere :)