Relax restriction of preferences to top-level packages #56575
Conversation
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
|
There will doubtlessly be tests that must be adjusted as we're breaking some assertions that I had previously made on purpose, but I think it's clear that users want this feature, so we should just do it. With this PR you should be able to have preferences that refer to packages that are not a top-level dependency in your current project (but that exist within a Manifest somewhere in your load path). This means that you can now have preferences applied to non-top-level deps, but also that you can have a |
|
Could something break if I have two packages that have the same name but different UUIDs ? |
|
Yes, that is what this check is intended to find. |
|
Couldn't LocalPreferences.toml specify UUID ? At least for the global preferences usage intended here |
|
Yes, we could have made that decision back when we first introduced the format, but we decided against it because (1) it is intended to sit in the same place as a |
Can it be introduced now, without it being a breaking change? |
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.tomllisting 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.tomlfile 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 aLocalPreferences.tomlfile in thestdlibdirectory 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