I made a little package to make it easier to set and get preferences (in the sense of Preferences.jl) interactively. It hooks into the Pkg REPL so you can do this:
pkg> preference add Plots default_backend=unicodeplots pkg> preference add Cthulhu enable_highlighter=true type_annotations=true pkg> preference add SnoopPrecompile skip_precompile+=DataFrames pkg> preference status Cthulhu enable_highlighter: true type_annotations: true Plots default_backend: "unicodeplots" SnoopPrecompile skip_precompile: ["DataFrames"]
Why use this?
- It provides a single consistent interface for modifying preferences. Many packages have functions to set their preferences, but with varying interfaces and levels of functionality. Package authors could instead instruct their users to set preferences with this package.
- The commands (
status) are consistent with the rest of the Pkg REPL so easy to remember.
- It allows you to set preferences before first loading the package - which may be important to avoid downloading a large unwanted default binary, or to avoid unnecessary precompilation. You can only do this with Preferences.jl if you know the UUID of the package.
- You can conveniently set global preferences with the
-gflag, and export them with the
- Fewer keystrokes - installed packages and existing preference names can be tab-completed.
- List-valued preferences can be modified with
-=, which is particularly useful for
Why not use it?
- Preferences are not validated at all - this does not check that the package name exists, or that a given preference name or value is valid for the package.
- Packages which consume preferences should still use Preferences.jl directly. This package is for interactive use.
Personally, I’m going to migrate some of my own packages (PythonCall, CondaPkg, Bokeh) to use preferences, instructing users to set preferences with this package.