Richard Feldman (Jul 20 2026 at 02:52): Richard Feldman (Jul 20 2026 at 02:52):so this is an idea that's been kicking around in my head for awhile, and I'd filed it away for "revisit around 0.1.0 because it really needs version numbers" and now that we're only months (hopefully!) away from 0.1.0, I figured it'd be a good time to start discussing it!
Richard Feldman (Jul 20 2026 at 02:53):the basic idea here is that there are various use cases where you may want to run some roc code
Richard Feldman (Jul 20 2026 at 02:54):an obvious example is the equivalent of cargo install or npm install -g - which is to say, "I want to install some sort of Rust JavaScript Roc utility program and run it several times later"
Richard Feldman (Jul 20 2026 at 02:54):I'd want to do this with URLs, like how we do with packages, which I think is a nice fit for this because people tend to copy/paste those off websites anyway
Richard Feldman (Jul 20 2026 at 02:55):so for example, tokei is a Rust "count lines of code in directories really fast" CLI, and it has this in the installation instructions:
cargo install tokei
now that relies on a global package namespace; I'm thinking of something more URL-based like our packages, e.g.
roc install tokei https://example.com/tokei/1.2.3/X73hGh05nNTkDHU06FHC0YfFaQB1pimX7gncRcao5mU.tar.br
so that command downloads and expands the contents of that URL into some persistent directory (so, not the global roc cache dir where we store downloaded packages, because these aren't cached; it's not intended that you'd clear them out and expect nothing bad to happen aside from cache misses)
Richard Feldman (Jul 20 2026 at 02:58):and then from then on, you could do things like:
roc run tokei
...to run it, assuming it's a roc application
Richard Feldman (Jul 20 2026 at 02:58):or, you could do this:
roc glue tokei
...assuming it's a glue spec
Richard Feldman (Jul 20 2026 at 02:59):or:
roc lint tokei
assuming we have a roc lint command (I want to have some sort of roc linting thing, likely inspired by elm-review, but maybe the subcommand would or wouldn't be roc lint - that part is TBD)
Richard Feldman (Jul 20 2026 at 02:59):etc.
Richard Feldman (Jul 20 2026 at 03:01):so the key feature here is that you can grab some roc code off the internet from an arbitrary URL, and while you're at it, you can also give it a shorthand name of your choice so that in the future you can refer to it concisely
Richard Feldman (Jul 20 2026 at 03:01):I assume just like how the real Rust tokei has a cargo install tokei line you can copy/paste, so too would the roc things that would be designed to use in this way. You'd be copy/pasting a longer line because of the URL, but it's still just copy-pasting a line
Richard Feldman (Jul 20 2026 at 03:02):and then if there's a conflict, e.g. you had already previously done roc install tokei https://... with some other thing named tokei (ok that probably wouldn't happen with literally the name tokei, but pretend it's a more common name) then it would be super easy for you to fix; you could just choose a different name and keep the url and you're all set
Richard Feldman (Jul 20 2026 at 03:07):other things that can be nice about this:
roc install can do an --opt=size build on it right after downloading it, so it always runs with optimizations (we don't have this for roc glue at the moment; it just always runs on the fly with no optimizations)roc update later which gives you a way to get new versions of these (design TBD)cargo install) plus current roc "compiler plugins" (like roc glue today), but also future compiler plugins such as for notebooks (we've talked about these elsewhere) and timing information for builds so that you can get flame graphs of how much time your roc program is spending in various places etc. Richard Feldman (Jul 20 2026 at 03:07):anyway the reason I bring all this up in the context of 0.1.0 is that I think this feature really kinda depends on having a version number, so you can install these under a version-specific directory that lines up with roc's compiler :sweat_smile:
Richard Feldman (Jul 20 2026 at 03:09):otherwise, you download something under a directory for the current nightly, and then you try to use it again later and it's broken and you have to go roc install a new release of it
Luke Boswell (Jul 20 2026 at 03:10):Richard Feldman said:
otherwise, you download something under a directory for the current nightly, and then you try to use it again later and it's broken and you have to go
roc installa new release of it
Honestly this wouldn't be terrible UX for now ... at least to validate the idea and build out the foundation
Richard Feldman (Jul 20 2026 at 03:11):yeah we should get it going before 0.1.0 so that when we ship 0.1.0 it's actually had some time to be battle-tested :laughing:
Luke Boswell (Jul 20 2026 at 03:13):Regarding this idea... I feel like there is a few different use cases mixed in here.
Is this primarily to solve the problem of using something from a URL, or is it the repeated use part?
To play devils advocate, why couldn't you just support roc https:/... and run directly from a URL and cache the thing?
Richard Feldman (Jul 20 2026 at 03:13):yeah we can do that too
Richard Feldman (Jul 20 2026 at 03:14):although in that scenario I'd probably not --opt=size
Richard Feldman (Jul 20 2026 at 03:14):that would basically be roc's equivalent of npx
Richard Feldman (Jul 20 2026 at 03:14):and we could do the same thing for roc glue etc - if you give a full URL, we just download it for you on the fly
Richard Feldman (Jul 20 2026 at 03:15):whereas if you give an identifier, it will look in roc installed things
Luke Boswell (Jul 20 2026 at 03:15):We could do roc build -g tokei http:///
Richard Feldman (Jul 20 2026 at 03:15):so yeah the purpose would just be "don't have to write out the URL every time, plus do optimizations once so it's faster every time"
Richard Feldman (Jul 20 2026 at 03:15):eh I don't like the idea of roc build being coupled to this registry of shorthands
Luke Boswell (Jul 20 2026 at 03:16):I'm coming from a position of "could we do this using the existing subcommands? do we need new subcommands?"
Richard Feldman (Jul 20 2026 at 03:16):hm, my default preference on this one is a separate subcommand because it's doing something different from other subcommands I think
Luke Boswell (Jul 20 2026 at 03:27):I feel like the "install and run roc programs from URL" part is good, I think it's the other aspects of this like "install and run glue or other compiler plugins" I'm less clear about.
If we supported using URLs for roc glue https//path/to/RustGlue.roc ... then I guess this is basically building an index of shorthand names like "tokei" or "rust-glue" for these URLs. And then the cli downloads and caches that file locally.
Is that an ok mental model?
Like you roc install <short name> <URL> and then anywhere we support a <URL> in the cli commands you can substitute the <short name>...
Richard Feldman (Jul 20 2026 at 03:46):yep, exactly!
Richard Feldman (Jul 20 2026 at 03:47):and then in the future you can update it to change to a different URL if a new version is out, and then you don't have to go around changing all your ci checks to point to a new URL or whatever :smile:
Richard Feldman (Jul 20 2026 at 03:48):and if you're telling ai agents to run things, you can just install them on your machine once and then not need to update your agents.md every time you want to update the roc thing etc
Luke Boswell (Jul 20 2026 at 03:54):I'll have a crack at pulling this together into a GH Issue in case anyone wants to implement it.
Luke Boswell (Jul 20 2026 at 04:16):Here is the GH Issue for this https://github.com/roc-lang/roc/issues/10265
I've marked it as Good First Issue as I feel someone less familiar with Roc specifically should be capable of working through this, despite it being a larger feature.
I've made a few assumptions like not adding roc run subcommand, or leaving roc update for later, how we manage different compiler versions etc.
I feel like this is a reasonable starting point for this but I've not spent a lot of time on this, just trying to synthesise @Richard Feldman's idea above. Please ask clarifying questions if you want to work on this.
Jasper Woudenberg (Jul 20 2026 at 06:15):I think the idea of making it super simple to install a Roc app is delightful, but my general feeling about these types of language-specific-program-installation systems (be it Python, Ruby, Makefiles) is apprehension. Together they create a situation where you have these many sources of installed packages, to update you need to remember how you installed a tool, and anyway that you need to update them manually is not great.
I wonder if this is the type of situation where it makes sense for each individual programming language to build functionality like this, but the sum effect of that is bad.
That said, I realize I might not be the target user here. I'd love some tooling to make it easy to install a Roc application using my package manager of choice, but realize that (A) this is much harder because there's so many package managers and (B) nothing is stopping such a project from existing separately from this idea.
Luke Boswell (Jul 20 2026 at 06:42):This isn't installing binaries into PATH like other package managers, the UX would be roc someapp to run it. Does this mitigate the concern with remembering how to manually update?
Kasper Møller Andersen (Jul 20 2026 at 07:01):I have the same apprehension, and I feel the modern and sensible solution is to leave this task to actual package managers. From a security point of view, if some piece of code is compromised for whatever reason, both users and defenders want to very easily know if a system is running that code. This requires good visibility into installed software, which you get with regular package managers.
Presumably, this is also the first step on a path that leads to things like build scripts being incorporated into the tooling (for when some Roc application requires some additional setup, like compiling a C library). This is another point where I would much prefer that we try to reuse what is already available with existing build systems: , rather than try and build our own.
Kasper Møller Andersen (Jul 20 2026 at 07:06):In other words, both this kind of install command and custom build systems come about often “just because we can”, and they seem sensible enough in isolation. But as a whole, I think they just make it harder for users to actually manage the software in their systems over time.
MagicMan (Jul 20 2026 at 07:09):How would this idea handle platforms? Would there be anyway too swap out the platform? E.g. --run-with=some_other_platform
Kasper Møller Andersen (Jul 20 2026 at 07:27):To rephrase a bit, I think one of the things we need more focus on in general in software is: how can our software be good citizens in the great big software world?
A big thing there is really to make sure that our software slots cleanly into the rest of the world, with clear dependencies, build steps, and orchestration in general, before we even start running the software. Broadly speaking, these are solved problems, and the more we try and do our own thing, the harder we make it for everyone else around us.
Bryce Miller (Jul 20 2026 at 12:53):I don’t think it would be very fun to need to use e.g. homebrew or nix easily grab a Glue spec.
Matthieu Pizenberg (Jul 20 2026 at 15:10):I personally do not like system package managers. The have their own quirks and differ from OS to OS. I always go for local user-land install managers. NPM for js, uv for python, cargo for rust, etc. They have much more insight into what’s possible with the language, and enable installation of programs for the user without admin access.
Jasper Woudenberg (Jul 20 2026 at 15:23):Luke Boswell said:
This isn't installing binaries into PATH like other package managers, the UX would be
roc someappto run it. Does this mitigate the concern with remembering how to manually update?
You're right, it'd be obvious that you need Roc to update such a package. You'd still need to manually do those updates though, and because it's a full roc app (including the platform), security vulnerabilities are a thing to worry about in this case. Though an updated design might periodically check for dependencies with updates and give you a warning, or something like that.
Richard, your examples are all development tooling, is the primary audience you have in mind for this (Roc) software developers? If so, would it make sense for this to be project-aware somehow, so you can pull in different versions of tools depending on the project?
Jasper Woudenberg (Jul 20 2026 at 15:27):Maybe the problem is how I think of this. An idea that excites me is being able to write down "roc tool aliases" in a .envrc or .nix file or something (shortname to URL) and have these automatically available in a development environment, and I guess with this idea you're there: Just put some roc install ... commands in an .envrc file.
Last updated: Jul 23 2026 at 13:15 UTC