You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Relax restriction of preferences to top-level packages
When preferences were first added, we originally did not have any
preference merging across load path [0]. We later added that [1], but
retained the requirement that for each individual element in the load
path, preferences must have an entry in `Project.toml` listing the
relevant package. This was partly on purpose (immediately binding the
name to the UUID prevents confusion when a UUID<->name binding is not
readily apparent) and partly just inheriting the way things worked back
when preferences was written with just a single Project.toml in mind.
This PR breaks this assumption to specifically allow an entry in the
Julia load path that contains only a single `LocalPreferences.toml`
file that sets preferences for packages that may or may not be in the
current environment stack. The usecase and desire for this is
well-motivated in [2], but basically boils down to "system admin
provided preferences that should be used globally". In fact, one such
convenient method that now works is to drop a `LocalPreferences.toml`
file in the `stdlib` directory of your Julia distribution, as that is
almost always a part of a Julia process's load path.
[0] #37595
[1] #38044
[2] JuliaPackaging/Preferences.jl#33
0 commit comments