Is there a way to prune the .julia/compiled folder? It is getting quite big.
The most conservative thing would likely be to do using Pkg; Pkg.gc() and see how much that removes.
But you You can just rm -rf .julia/compiled (or more specific subdirectories in there) if you want. When you load packages, julia will start over recompiling them and re-create the .julia/compiled folder as needed.
I do this every once in a while if I end up with a bunch of compiled code I don’t want.
2 Likes
Especially there is folders for each version of Julia:
(base) felix@saturn:~/.julia/compiled$ ls
v1.10 v1.11 v1.8 v1.9
Deleting v1.8 and v1.9 is fine if you don’t use the older versions anymore.
6 Likes
For some packages, I see multiple DLLs and .ji files. For instance, I have four Makie DLLs each with 130 MB. Is it safe to delete the old ones?
It is always safe to deleted anything in .compiled it’s a pure on disk cache and Julia will recreate it if necessary
4 Likes
Is there a core mechanism that gets rid of unused stuff or will .julia grow indefinitely?
Pkg will run garbage collection every now and then but .julia does somewhat have a tendency to grow indefinitely.
2 Likes
I think users tend to gripe a lot more about unexpected recompilation of stuff they’ve used before than about an extra 5GB of hard drive space used, so it’s probably best to be somewhat conservative in what to prune.
1 Like
It is 70 GB in my case.
5 Likes
That’s rather impressive. Do you by chance have a lot of julia versions in there?
1 Like
I had about 50GB in my home folder on our HPC which has limited user-space. Thankfully, it was simply a matter of deleting compiled folders for version < 1.11.
Is there other folders that can be deleted safely? (I have another HPC with even more limited home space, about 6GB)
I have a cron job that rm -rf the .julia folder and reinstalls my registries.
1 Like
I would not recommend deleting the entire .julia folder since there are some items in there that you may not want to delete and which are also quite small. For example:
- The default version specific environments in
.julia/environments - Your REPL command history in
.julia/logs - Packages that you may have
deved and edited in.julia/dev - Configuration such as your startup.jl in
.julia/config - Pluto notebooks in
.julia/pluto_notebooks
I would consider clearing out the following, especially if you have used Julia for a long time:
.julia/compiled(will be automatically recompiled).julia/artifacts(artifacts that have not been used in a while can be removed).julia/scratchspaces(these should be transient and be reinstalled).julia/packages(can be reinstalled viaPkg.instantiate())
Pkg.gc() does better than in the past for recent installations. There is also juliaup gc if you are a juliaup user. You may also want to look at GitHub - giordano/PkgCleanup.jl: Cleanup unused Julia environments and artifacts .
6 Likes
Why is there no mechanism in Julia to remove the old version of a package if I have updated it? At least an option. I know there is no ONE version, it soly depends on the environments I am using. But having 50 GB of “stale” stuff is not acceptable.
I have to say even though in Python package management is really poor (it got a lot better with uv) but at least with virtual environments you do not have this problem. The code is simply right there. And there is no point in having any other packages or old version in that .venv.
I guess having it locally per environment has its charme.
2 Likes
You mean directly? Because it’s unsafe. Say you remove SomePackage v0.3.5 today because your environments for the last year all use v0.4+, but next month you need to reproduce some old script from a few years ago. So you blow the dust off and activate that environment, but everything’s broken for some reason you can’t remember and activate cannot tell, so you manually instantiate.
The cost of lightweight environments depending on systemic installation is management has to be systemic and opinionated. It might’ve been a reasonable choice to only track recently activate-d environments and expect us to instantiate the others, but somebody decided not to surprise us like that, so we have the responsibility of getting rid of manifests so Pkg.gc can do its work. Last time I checked (well, eyeballed), gc only seems to modify /packages and /artifacts, not /compiled. I don’t expect it to be controversial for gc to handle that too, but for all I know, maybe someone decided that it’d be better to keep those around to keep precompilation times down. More clarity and options would indeed be nice.
1 Like
Pkg.gc (already mentioned above) does literally that, as long as there’s no active manifest keeping an older version necessary.
2 Likes
What is “active” manifest? How would I deactivate it?
1 Like
I would not expect that to work, without any hassle. In the meantime I probably have updated Julia.
1 Like
I don’t know where it’s internally stored, but Pkg keeps track of the paths to the manifests of all the environments you’ve ever activated. Pkg.gc determines what dependencies to keep by going through all these manifests, analogous to garbage collection determining what objects to keep by going through the program’s references. The verbose option (] gc -v) prints out the active manifests before doing the cleanup. If you delete a manifest file then go through Pkg.gc, it’ll be untracked. PkgCleanup.jl is a way to untrack manifests from one place rather than more drastic measures at every listed path manually.
Well yes, you do need to start a session with a Julia version matching the manifest’s. But the point of an active manifest is to record all the already installed dependencies to load when you activate its environment, skipping installation and precompilation. If that doesn’t work, something has gone wrong, like if Python’s isolated virtual environments just lost packages, or you never activated the environment in the first place, like if someone provided you with a requirements.txt file.
1 Like
In the same folder? How would do that? I simply delete the whole folder. Or does it check if the manifest at that path still exists?