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.
Is it possible or foreseen to be able start Julia with the default depot path, ignoring the environment variable JULIA_DEPOT_PATH even if it was set. I would have a use case for that, where an installer ships with its own runtime and sets the JULIA_DEPOT_PATH. Normally, this is done on a machine that does not have Julia, so no problem there. But for testing, we might use a PC where Julia is installed and, of course, we would like that installation to work with the default path, not the one that is set by the installer.
So first, I think that is more of a question re Julia itself at the moment, as Juliaup no longer depends on JULIA_DEPOT_PATH at all (that was the anouncement here, that Juliaup now uses JULIAUP_DEPOT_PATH).
But even so, not clear to me how that kind of thing could be implemented. I guess (maybe) one could have a command line argument that has higher precedence than the env variable? But I think at the end of the day the better solution here would be that this installer provides some kind of option to say “hey, use this depot, rather than your own”.
