Preferences without a UUID mapping silently ignored in stacked environments

[topolarity]

In a stacked environment (just a local --project=. + the global env), Preferences will silently ignore LocalPreferences.toml entries if:

1. The referenced package name is in a different stacked environment.
2. The package where the Preference is coming from has no UUID mapping for the package name.

(@v1.10) pkg> status
Status `~/.julia/environments/v1.10/Project.toml`
⌅ [aea7be01] PrecompileTools v1.2.1

(@v1.10) pkg> activate .
  Activating project at `~/test-environments/rAI-Plots`

(rAI-Plots) pkg> status
Status `~/test-environments/rAI-Plots/Project.toml`
  [cd3eb016] HTTP v1.10.16
  [91a5bcdd] Plots v1.40.13
  [21216c6a] Preferences v1.4.3

shell> cat LocalPreferences.toml
[PrecompileTools]
precompile_workloads = false

julia> using Preferences
julia> Preferences.load_preference("PrecompileTools", "precompile_workloads", "no preference!")
"no preference!

If you try to load the package and do set_preference!(...), it will yell at you but it will also fix your bug:

julia> using PrecompileTools

julia> Preferences.set_preferences!("PrecompileTools", "precompile_workloads"=>"false")
ERROR: ArgumentError: Cannot set preference 'precompile_workloads' to 'false' for PrecompileTools in /home/topolarity/test-environments/rAI-Plots/LocalPreferences.toml: preference already set to 'false'!

julia> Preferences.load_preference("PrecompileTools", "precompile_workloads", "no preference!")
false

because this will add the missing [extras] entry to your Project.toml so that you have a UUID mapping for the preference:

shell> cat Project.toml
[deps]
HTTP = "cd3eb016-35fb-5094-929b-558a96fad6f3"
Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"
Preferences = "21216c6a-2e73-6563-6e65-726566657250"

[extras]
PrecompileTools = "aea7be01-6a6a-4083-8856-8a6e6704d82a"

[StefanKarpinski]

@staticfloat is this by design? @KristofferC might also know.

[staticfloat]

This is fixed by JuliaLang/julia#56575, so if we want this behavior (specifically, to allow looking up preferences whose UUIDs are not saved within exact Manifest.toml that is co-located with the LocalPreferences.toml or Project.toml the preference is defined in) then we should merge it.

[topolarity]

To be clear, there's also a bug here even if we don't take up that behavior IMO

Normally Preferences will complain loudly (yay!) about the missing mapping:

julia> Preferences.load_preference("PrecompileTools", "precompile_workloads", "no preference!")
ERROR: ArgumentError: Cannot resolve package 'PrecompileTools' in load path; have you added the package as a top-level dependency?

It just doesn't do this if the mapping is provided somewhere else in the stacked environment (even though it doesn't actually use the mapping, either)

[topolarity]

I guess technically that's an error in resolving "PrecompileTools" in your query, which isn't the same as the error in resolving "PrecompileTools" in your LocalPreferences.toml (which also happens here, silently)

Still, it seems like there should be a way to surface errors from parsing / resolving LocalPreferences.toml

[staticfloat]

Normally Preferences will complain loudly (yay!) about the missing mapping:

Yes, I agree that this "cannot resolve" error should follow the same logic as Base when it collects preferences.