build cache location and dependency downloads · beginners

Stream: beginners

Topic: build cache location and dependency downloads

Krzysztof Skowronek (Aug 18 2026 at 20:13):

where are the build artifacts located? I know I can run roc build --no-cache but I was expecting to also have roc clean or something like, or at least be able to manually clear the cache (think the bin folder from dotnet or target from Rust)

also, I tried running roc build at work (because of course I did), but the corporate firewall blocked the platform download. Will there be a way to configure the packages/platforms sources to go through something like artifactory? I think it's a must if Roc is to be used in bigger companies.

Richard Feldman (Aug 18 2026 at 22:04):

great questions! There is one global cache dir - not sure what OS you're on, but on macOS it's in ~/.cache/roc/

Richard Feldman (Aug 18 2026 at 22:04):

if you want to clean it, you can just delete it

Richard Feldman (Aug 18 2026 at 22:06):

but in general the way it works is:

downloaded packages stay in there indefinitely, and roc looks in there before attempting to use the Internet, so if you can copy a downloaded package in there from somewhere else, that should address the firewall issue for now (I hear you that it's not a great UX right now!)
old build artifacts (based on date of last use) get automatically cleaned up during roc builds, so you shouldn't need to clean them manually

Richard Feldman (Aug 18 2026 at 22:10):

the design goals here are:

there's nothing to add to .gitignore - projects don't make a mess in your local dir, which is valuable for the scripting use case if you want to have dependencies
all builds automatically share everything, including not just downloaded packages but also intermediate build artifacts - so that means if you have multiple checkouts of the same project, or which share a bunch of code, they will all automatically share relevant build artifacts behind the scenes and you won't be paying for redundant copies of packages or build artifacts (just the source code itself)
roc cleans up after itself when it comes to build artifacts, so you don't need to "periodically clean things" to prevent your disk from filling up
packages stay downloaded indefinitely, on the theory that build artifacts can be regenerated from source code + packages, but packages can't, so deleting them automatically would mean you could no longer build without being able to re-download, which would be bad. Also, cached packages only grow when you add a new one, as opposed to on every single build, so their growth trajectory is less much lower than cached build artifacts

Krzysztof Skowronek (Aug 18 2026 at 22:21):

maybe it would be nice to have a command to open the build artifact directory? maybe even per file you are trying to run?

Luke Boswell (Aug 18 2026 at 22:23):

Richard Feldman said:

Also, cached packages only grow when you add a new one, as opposed to on every single build, so their growth trajectory is less much lower than cached build artifacts

Another aspect to this is you only need to make a network request if you don't already have packages in your cache... because packages are content-hashed we can know for certain if you have the exact files locally and there is never any need to check. So the cli can download once, and then re-use that cached package (includes platforms) every time.

Krzysztof Skowronek (Aug 18 2026 at 22:33):

ok, on windows it's ~\AppData\Local\roc - good location I'd say, however there is only a directory for packages

I've built some examples on this machine, and I can't see anything related to the compilation - maybe that's why the --no-cache didn't do much?

Krzysztof Skowronek (Aug 18 2026 at 22:37):

the global cache for packages is something I'm familiar with, that's how nuget works in dotnet - all packages go through ~/.nuget as a global cache

is there roc restore to just download everything? we use dotnet-subset to copy only the dependency related parts of the codebase, then run dotnet restore to cache a docker layer with all dependencies baked in

maybe could be a nice thing for roc also

Luke Boswell (Aug 18 2026 at 22:48):

Package cache %LOCALAPPDATA%\roc\packages
Build cache %APPDATA%\Roc

Anton (Aug 19 2026 at 14:04):

is there roc restore to just download everything?

We don't have this yet, shall we name this roc fetch?

Krzysztof Skowronek (Aug 19 2026 at 14:28):

In principle the docker layer should just copy the main.roc file, and then use this new roc fetch main.roc, right?

Anton (Aug 19 2026 at 14:38):

Yeah, that sounds like it should work (once we implement roc fetch)

Richard Feldman (Aug 19 2026 at 14:59):

if you just want it to download everything, roc check will already do this

Richard Feldman (Aug 19 2026 at 14:59):

I don't think we need a separate subcommand for that :smile:

Krzysztof Skowronek (Aug 19 2026 at 15:02):

So the idea is to have a layer that is cached until the dependencies changed, so we would copy just main.roc that lists them

Roc check would fail usually for that, because of actually looks at the code

Anton (Aug 19 2026 at 15:14):

roc check will already do this

roc check could take up significant time on a big project so it would be nice to be able to do just roc fetch on a low spec CI machine.

Richard Feldman (Aug 19 2026 at 15:21):

hm but what's the use case there? What's the situation where you want to download the deps and then not do anything with them? :thinking:

Krzysztof Skowronek (Aug 19 2026 at 15:27):

In dockerfile

You do:

copy roc.main .&& Roc fetch
Copy . . // Can't remember syntax for copy all
Roc build main.roc

The layer that has only the main will not be recomputed until your dependencies change, removing the download

With good caching setup, all your runners share the .cache/roc/packages state, until you change the main.roc file

Krzysztof Skowronek (Aug 19 2026 at 15:27):

You could even go one step further and make it prepare build cache artifacts for dependencies, so that can also be shared

Richard Feldman (Aug 19 2026 at 15:38):

I see, that makes sense. What name do mainstream CLIs use for this operation?

Krzysztof Skowronek (Aug 19 2026 at 15:41):

Npm does install, cargo does fetch, dotnet does restore, go has mod download - I don't think there is a standard

Richard Feldman (Aug 19 2026 at 15:42):

download sounds the most direct, except that if I see roc download I immediately think "...download what?" - like it feels like it should have another argument haha

Richard Feldman (Aug 19 2026 at 15:43):

I guess roc fetch is probably the best option among those

Krzysztof Skowronek (Aug 19 2026 at 15:43):

roc deps main.roc? Would be great if it also precompiled the dependencies if that's happening at any point

Krzysztof Skowronek (Aug 19 2026 at 15:44):

Btw, dotnet even has dotent build --no-restore to fully skip even checking if restore is needed

Richard Feldman (Aug 19 2026 at 15:59):

roc deps sounds to me like it's going to tell me what the dependencies are :smile:

Hannes (Aug 20 2026 at 04:20):

To add another alternative, Gleam has gleam deps list for listing and gleam deps download for downloading.

Last updated: Sep 03 2026 at 15:16 UTC