# PSA: Breaking change how juliaup interacts with JULIA\_DEPOT\_PATH
**URL:** https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497
**Category:** Tooling
**Tags:** juliaup
**Created:** [November 20, 2023, 11:18pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497 "2023-11-20T23:18:02Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [November 20, 2023, 11:18pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/1 "2023-11-20T23:18:02Z")
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.
---
### Author:  [@thofma](https://discourse.julialang.org/u/thofma)
#### Post date: [November 22, 2023, 6:01pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/2 "2023-11-22T18:01:13Z")
What is the default for the new variable (if it is not set)?
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [November 22, 2023, 7:37pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/3 "2023-11-22T19:37:35Z")
Just the standard Julia depot, i.e. `~/.julia`.
---
### Author:  [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [November 23, 2023, 8:19am UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/4 "2023-11-23T08:19:46Z")
Would it not be better then to fully decouple them? If someone really wants them to be coupled you can do set `JULIAUP_DEPOT_PATH=~/.julia`.
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [November 23, 2023, 8:30am UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/5 "2023-11-23T08:30:58Z")
Would be cool to have the default be using [BaseDirs.jl](https://juliahub.com/ui/Packages/General/BaseDirs), to be more consistent with what various OS expect/have as their default.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [November 23, 2023, 6:48pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/6 "2023-11-23T18:48:05Z")
> [@fredrikekre](#):
>
> Would it not be better then to fully decouple them?
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.
> [@Sukera](#):
>
> Would be cool to have the default be using [BaseDirs.jl](https://juliahub.com/ui/Packages/General/BaseDirs), to be more consistent with what various OS expect/have as their default.
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).
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [November 23, 2023, 6:51pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/7 "2023-11-23T18:51:44Z")
> [@davidanthoff](#):
>
> 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 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](https://docs.julialang.org/en/v1/base/constants/#Base.DEPOT_PATH) 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.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [November 23, 2023, 6:57pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/8 "2023-11-23T18:57:21Z")
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.
> [@Sukera](#):
>
> since they are really third party tools
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.
---
### Author:  [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)
#### Post date: [November 24, 2023, 3:49am UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/9 "2023-11-24T03:49:46Z")
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.
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [November 24, 2023, 6:12am UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/10 "2023-11-24T06:12:06Z")
> [@StefanKarpinski](#):
>
> 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
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.
---
### Author:  [@okartal](https://discourse.julialang.org/u/okartal)
#### Post date: [October 31, 2024, 1:27pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/11 "2024-10-31T13:27:47Z")
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.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [October 31, 2024, 5:47pm UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/12 "2024-10-31T17:47:12Z")
> [@okartal](#):
>
> 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.
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”.
---
### Author:  [@okartal](https://discourse.julialang.org/u/okartal)
#### Post date: [November 7, 2024, 7:57am UTC](https://discourse.julialang.org/t/psa-breaking-change-how-juliaup-interacts-with-julia-depot-path/106497/13 "2024-11-07T07:57:07Z")
Thanks David, sorry, I missed the “UP” there. Will pursue this as another topic.