RFC: use Preference system for julia itself

[Roger-luo]

I think now with the preference system, it would be nice to configure julia itself withit per environment, e.g

• one may want to use -J<path to system image> per project environment
• one may want to set compile=min or -O1 or other compiler flags for certain project while developing
• one may want to disable/change the colors/number of threads etc. of Julia REPL without borthering the environment variables per project
• more fine tuned and structured color preference of the REPL, error message etc. with TOML (making whoever doesn't like the current color scheme happy)

not all of the above is achievable/convenient by messing up system environment variables, from user experience if we support the new configure system
one can:

• configure their julia configuration for each project within julia REPL (instead of learning shell script/windows environment variable) directly with Preferences.jl
• keep all the julia preferences in one file under .julia which is seperate with .bashrc/.zshrc etc. this will make it easier to migrate the same preference to cluster etc.

my proposed implementation is to support a special field like following

for Project.toml

[preferences.julia]
sysimage="min"
nthreads=16

[preferences.julia.color]
error="light_blue"
line_number="green"

for LocalPreference.toml

[julia]
sysimage="min"
nthreads=16

[julia.color]
error="light_blue"
line_number="green"

---

edit: I realize not all the options can be configured easily using the preference system since it seems to require loading stdlib TOML.jl first, which means things implemented in C won't be able to configured afterwards, but still would be nice to be able to configure things within REPL itself (even by restart REPL to activate the new configuration)

[staticfloat]

The first step for this is to print Preferences.jl in as an external stdlib, just like Pkg or Tar.

[fredrikekre]

Why? That doesn't seem necessary. There is a TOML parser in base already.

[Roger-luo]

I actually tried to implement this myself, I don't see the need of using Preferences.jl inside Base? or I could be wrong, I think we need a list of configurations that should go into the julia preference field first (I'll init a list of them here I found later). For whoever sees an issue related to perference or could be configured, maybe link to this issue

And the other problem is should we special case the julia since I don't think julia has a UUID as a package right? or it has? I'm not sure what does this do: https://github.com/JuliaRegistries/General/blob/master/J/julia/Package.toml

or should this UUID be recognized as the Julia UUID?

[staticfloat]

or should this UUID be recognized as the Julia UUID?

Yes, the UUID of Julia itself is 1222c4b2-2114-5bfd-aeef-88e4692bbb3e. We use that all over the place in Pkg.

There is a TOML parser in base already.

I guess if we don't want to support writing preferences, and we don't care about marking .ji files to contain their list of compile-time preferences, then the only thing we really need is:

function load_julia_preferences()
    # Re-use definition in `base/loading.jl` so as to not repeat code.
    d = Base.get_preferences(Base.UUID("1222c4b2-2114-5bfd-aeef-88e4692bbb3e"))
    # Drop any nested `__clear__` keys:
    function drop_clears(data::Dict)
        delete!(data, "__clear__")
        for (k, v) in data
            if isa(v, Dict)
                drop_clears(v)
            end
        end
        return data
    end
    drop_clears(x) = x

    return drop_clears(d)
end

# Initialize JULIA_PREFS with a value so it can be used at compile time
const JULIA_PREFS = Ref{Dict}(load_julia_preferences())
function __init__()
    # Re-initialize JULIA_PREFS at `__init__()` time, so that users can make changes to things that are not compile-time sensitive
    JULIA_PREFS[] = load_julia_preferences()
end

And we tell users "if you want to modify the preferences, you either edit them by hand, or you use Preferences.jl from an already-running Julia instance.