Stream: ideas

Topic: Roc version management

Tanner Nielsen (Jan 31 2023 at 05:26):

Today I stumbled upon asdf, a general purpose version manager. Not sure if it would go against the Roc philosophy, but an asdf plugin for Roc would be nice! Especially for downloading the nightly builds over and over. Just throwing this out there in case it hasn't been discussed before.

Anton (Jan 31 2023 at 10:40):

Hi @Tanner Nielsen, this has come up before here. We plan on supporting asdf after our 0.1 release.

There are no blockers to include upgrade functionality in the roc CLI however. Does anybody have any objections?

Richard Feldman (Jan 31 2023 at 16:57):

I definitely would like the roc CLI to be able to self-update! I haven't looked into it, but my hope would be that the following would be possible:

• You can run roc use 0.1 and it will switch your roc CLI to use version 0.1
• if you didn't already have it, it downloads the Roc 0.1 CLI binary from a known URL into your roc cache dir (we already have this cache dir concept set up for package downloads)
• once it has the binary downloaded, it replaces the current roc with the downloaded one, such that the next time you run roc, it's 0.1 (this should be possible, although on some operating systems it may require tricks like spawning a detached background process which waits until the original roc process has exited and then replaces the binary; it's important that the binary actually be replaced and not be a symlink, as having it be a symlink makes startup time worse. Adding roc use functionality must not decrease the performance of running roc even a little bit!)
• this works with any Roc version, which means we need to teach 0.1 how to do it before releasing 0.1, even though it won't have any other versions to switch to yet (otherwise if you did roc use 0.1 and then roc use 0.2 it wouldn't work because the 0.1 binary wouldn't know how to switch to others!)

Richard Feldman (Jan 31 2023 at 16:57):

Nix is a special case here, because overriding what an installed binary does is very much against the Nix philosophy (and would normally get a permissions issue anyway) - but since Nix would build from source anyway, we could have it build using a source flag that changes this feature to have roc use print "this isn't supported on Nix" and explain why

Anton (Jan 31 2023 at 17:08):

Sounds good, what do you think of supporting roc use latest-nightly as well?

Anton (Jan 31 2023 at 17:09):

I don't love use though, use feels temporary, and you're doing a "permanent" upgrade.

Kevin Gillette (Jan 31 2023 at 17:10):

I'm not sure symlinks affect performance that much in practice. If the OS has a decent fs cache implementation, then symlinks in the cache (and the files/binaries they point to) shouldn't need actual disk accesses after the first time, at least until something pushes it back out of the cache.

Kevin Gillette (Jan 31 2023 at 17:13):

Can we have a project optionally declare the Roc version it depends upon (either a minimum or an exact pin), so that roc use isn't needed for reproducibility?

Kevin Gillette (Jan 31 2023 at 17:18):

I would think roc could replace the binary if the requested is newer and passes self-checks, but otherwise roc could just use a managed config file with exec. With a warmed cache, mechanism would be non-free but still too quick to notice in practice (if the overhead cost of exec were noticable, shells would be considered unusable)

Kevin Gillette (Jan 31 2023 at 17:22):

Also, at least on earlier versions of windows, i don't believe you can atomically rename over a running binary, forcing the use of a helper program or other tricks (copy running binary then exec to that then copy new binary to install location then exec to that and remove temporary?)

I don't know if they've addressed that limitation yet

Anton (Jan 31 2023 at 17:27):

Can we have a project optionally declare the Roc version it depends upon (either a minimum or an exact pin), so that roc use isn't needed for reproducibility?

I've been thinking that as well, I'd like to put it in the project's main.roc

Richard Feldman (Jan 31 2023 at 19:15):

Kevin Gillette said:

Can we have a project optionally declare the Roc version it depends upon (either a minimum or an exact pin), so that roc use isn't needed for reproducibility?

yeah I think this could be in the root module header

Richard Feldman (Jan 31 2023 at 19:16):

Anton said:

I don't love use though, use feels temporary, and you're doing a "permanent" upgrade.

maybe roc switch? :thinking:

Richard Feldman (Jan 31 2023 at 19:16):

Kevin Gillette said:

I'm not sure symlinks affect performance that much in practice. If the OS has a decent fs cache implementation, then symlinks in the cache (and the files/binaries they point to) shouldn't need actual disk accesses after the first time, at least until something pushes it back out of the cache.

another issue with symlinks is that it means you kind of need an installer of some sort; you can't just put the binary in one place and then expect it to still be there

Kevin Gillette (Jan 31 2023 at 21:43):

I'm not necessarily in favor of symlinks. I just don't think their performance is a concern (micro-optimization).

I'd be more in favor of roc commands generally knowing how to download newer versions and how to invoke older versions via exec, and having roc store local compiler versions in a managed location so that they can be reliably found (essentially equivalent to an asset/package cache)

Last updated: Jun 16 2026 at 16:19 UTC