This is a short note that I am about to push a breaking update for Juliaup to everyone that changes how Juliaup interacts with JULIA_DEPOT_PATH. This is a pretty esoteric topic, so for most users of Juliaup, it is probably entirely safe to ignore this
The short version is that from now on one should use the JULIAUP_DEPOT_PATH environmental variable to configure into which depot Juliaup will put its configuration. Previously one could change that via the JULIA_DEPOT_PATH environmental variable, but that is now ignored by Juliaup.
There was some back and forth about that in the PR that implement that, but in the end I opted for this, in the end I think it is good if by default Julia tries not to create too many different folders where stuff goes. It also would have been more difficult to pick a different default without breaking existing installs.
Yeah, I guess that is a much larger question, whether Julia should move away from this model of having one folder where pretty much everything goes, but that would affect not just Juliaup but really many more parts of Julia. I think what I would really like to see (at some point) is a split of .julia into one folder that contains stuff that is purely “cache” like, i.e. one can delete it without any worries and it can just always be either recreated or redownloaded (registry cache, precompile cache, artifacts etc) and “real” user data that is valuable (dev folder, settings etc).
I think it’s quite unexpected/not good that lots of packages just dump their stuff into the julia depot. The depot isn’t really meant for that, as I understand it. Even the docs say it’s for Pkg and some internal code loading caches:
A stack of “depot” locations where the package manager, as well as Julia’s code loading mechanisms, look for package registries, installed packages, named environments, repo clones, cached compiled package images, and configuration files.
I’ve always found it odd that Pluto, juliaup etc. coopted that instead of going for more traditional XDG/OS-API based installations, since they are really third party tools that happen to be built for or implemented in Julia.
Yeah, I’m not saying that I’m opposed to a different model that is more aligned with platform specific locations, but in my mind that would need to be done holistically for Julia and Juliaup. The worst of all worlds (IMO) is if some parts of Julia use the “everything goes into .julia” and others follow a different philosophy. Fixing the previous Juliaup implementation was a high priority for a lot of folks and I didn’t want that to be entangled in a long redesign of general save locations.
That is not the idea for Juliaup, we are clearly moving to make it the default installer for Julia and a tightly integrated part of Julia itself.
While I’m all in favor of allowing XDG as something people can opt into easily, I’m against using it as a default. It’s only a thing people expect on Linux, and even there the vast majority of users have no idea about the variety of places where XDG suggests things go. It’s much more user friendly for all Julia-related things to go in a single place, especially since that’s that only approach that makes sense across platforms.
Yes, that’s why BaseDirs.jl uses XDG only on linux and uses macOS and windows specific places (i.e., the places people on those platforms expect) there, and not XDG.
