Package ergo for easier install/updating

[calebzulawski]

The existing installer is fine, and should continue to exist for anyone not using other alternatives, but packaging a few other ways would be convenient and can be automated upon release:

• Docker Hub
• Conda
• Homebrew
• Snap

[afranchuk]

I'm not very familiar with snap. Does it allow the application to interact outside of its sandbox easily (I was under the impression it's better for self-contained apps)?

[calebzulawski]

I spent some time yesterday looking into it. It's possible, but really not a great choice for us:

• Apparently snap packages aren't allowed to access dotfiles?
• We would need "classic" confinement mode, which requires manual approval
• We would need to manually request the aliases for ergo and ergofmt, otherwise they will only be accessible as ergolang.ergo and ergolang.ergofmt (users could add their own aliases, but this is inconvenient)

I'll probably just make regular deb and rpm packages.

[afranchuk]

What advantage do deb and rpm packages have over the installer? Specifically, do they offer any more integration with the system aside from package manager update/uninstall management?

[calebzulawski]

I was mostly thinking about an update path, but the shell installer really is good. I've been thinking another idea over, taking a page from cargo:

• Continue using the shell installer, but modify it to install to something like .ergo/versions/default and symlink .ergo/bin to .ergo/versions/default/bin
• Add an ergolang update which does some github API magic and pulls the latest version and installs it to .ergo/versions/default
• Support installing other versions of ergo in .ergo/versions/<version>, internally using the installer as well
• Support .ergo.toml or some equivalent that can specify an ergo version. Have ergolang read this file and forward arguments to .ergo/versions/<version>/bin/ergolang (some commands like update or uninstall won't forward to other versions, of course)
• Add an ergolang uninstall, so you don't need to keep the installer around
• Add an install.sh to the root of the repo that automatically picks the right installer for your system and downloads it, to make the initial install a bit easier

I think I can implement all of this pretty easily, what do you think?

[afranchuk]

I was mostly thinking about an update path, but the shell installer really is good. I've been thinking another idea over, taking a page from cargo:

* Continue using the shell installer, but modify it to install to something like `.ergo/versions/default` and symlink `.ergo/bin` to `.ergo/versions/default/bin`

* Add an `ergolang update` which does some github API magic and pulls the latest version and installs it to `.ergo/versions/default`

* Support installing other versions of ergo in `.ergo/versions/<version>`, internally using the installer as well

* Support `.ergo.toml` or some equivalent that can specify an ergo version.  Have `ergolang` read this file and forward arguments to `.ergo/versions/<version>/bin/ergolang` (some commands like `update` or `uninstall` won't forward to other versions, of course)

* Add an `ergolang uninstall`, so you don't need to keep the installer around

* Add an `install.sh` to the root of the repo that automatically picks the right installer for your system and downloads it, to make the initial install a bit easier

I think I can implement all of this pretty easily, what do you think?

My complaint with this is that it's not taking a page from cargo: it's taking a page from rustup. I.e., I'm more comfortable with this functionality in a separate tool (because e.g. ergolang uninstall/ergolang update would necessitate separate scripts anyway since binaries need to be replaced). I think a slightly simpler approach to the multi-versioning would be

• install to ROOT/bin/ergolang-<version> and ROOT/lib/ergo-<version>
• symlink default to ROOT/bin/ergolang (no need to symlink libs)
• standalone scripts and workspace files have a shebang with the version (e.g. #!/usr/bin/env ergo-x.y.z)
• ergolang evaluate will check for a shebang and exec if it sees one?

As far as update/uninstall goes, I'm not necessarily convinced more complexity there is warranted yet given there isn't a rapid release cycle.

[calebzulawski]

I think binary replacement isn't really an issue (rustup has rustup self update after all), but having it in a separate binary is fine, it's just more to package. I was actually thinking ergo isn't complicated enough to warrant a dedicated update tool separately versioned.

A shebang is probably fine, but it requires having ergo on your path as opposed to some known relationship between the various ergo installs. Something like path/to/cargo +nightly ... of course works without having anything on your path, but the difference is probably pretty minor. We don't package for windows (yet?) but a shebang isn't cross-platform. Putting it in the workspace sounds fine to me, though, what about an ergo-specific comment that serves as a directive?

Also, installing to ergolang-<version> etc sounds pretty good, but it won't work with any existing ergo releases, which is my motivation for now.