JULIA_ENV

[vtjnash]

instead of allowing using to take arguments, I thought it might make sense to provide a global dictionary CONFIG of type Dict{String, Any}, roughly equivalent to ENV that could take arbitrary configuration parameters.
e.g.

CONFIG["PyCall/Python"] = "/usr/bin/python2"
CONFIG["gfx/backend"] = "gtk" # shared graphics property using pseudo-group "gfx"
CONFIG["Winston/backend"] = "tk" # graphics override for Winston
CONFIG["answer_color"] = "green" # a configuration property currently in ENV["JULIA_ANSWER_COLOR"]
CONFIG["OUTPUT_STREAM"] = PipeBuffer() # properties don't need to be strings

(note the convention that items in base will be only names, whereas Modules should prefix their variables with their uppercase module name, or a meaningful lowercase string if it is a shared option)

and then we can also allow a callback notification function to be registered which can do additional work and/or disallow changes:

CONFIG_cb["OUTPUT_STREAM"] = function(new_val, old_val)
    if isa(new_val, IO)
        OUTPUT_STREAM = new_val
        true
    else
        false
    end
end

edit: replaced JULIA_ENV variable with CONFIG

[pao]

Mailing list is good for people who might not constantly F5 their GitHub notifications page.

[StefanKarpinski]

I like it. I wonder if it should be a hierarchical data structure or just flat with slashes in the keys like you have here. Also, calling it CONFIG might be good.

[mlubin]

Not opposed but this has the potential to start looking ugly.

[StefanKarpinski]

How come, @mlubin? Is there something you can think of that would be cleaner?

[mlubin]

I guess I'm worried more about the documentation issue and trying to figure out which magical string changes the property you want.

[vtjnash]

I had the same thought that autocompletion / declaration / checking would be nice, but felt this was at least better (more informative) then setting random environment variables, and I wanted something that could be set independently of whether it was actually needed at any given time.

But, let's expand the convention to suggest a module should set values for all keys it cares about (to make discovery easier), and provide a assign_weak() or assign_default() method to make it easy or, borrowing syntax from other languages like make, CONFIG["gfx/backend"] ?= "tk"

Agreed, CONFIG (and CONFIG_cb) sounds like a better name. I'll edit the original post to replace JULIA_ENV with CONFIG.

I initially considered Dict{String, Dict{String, Any}} -- where the first string would be the name of a module -- but thought this would be much more difficult to use, since then you have to first check whether the dictionary exists on every read & write. This could be wrapped in a custom hierarchal dict implementation to hide that difficulty from the user. However, it seemed to be that the only benefit was the convention was more strongly enforced and / would be more simply allowed as part of the key (which it is anyways).

[JeffBezanson]

Ah, the julia registry :)
These could be module-local, e.g. Winston.config["backend"]. Or possibly even just a naming convention instead of a data structure, e.g. Winston.config_backend("tk").

[vtjnash]

I wanted something independent of whether a module had been loaded, so you could set values prior to loading the module. And I figured that a dictionary in Base is easier and less cluttered than making accessors for every possible config value.

I guess it is essentially a julia registry. Well, in that case, I can only assume we should probably implement this using JSON, following the trend of past OS registries using what seemed to be the storage system of the day.

[quinnj]

FWIW, I agree with Jeff's idea of CONFIG dictionaries (or JSON structures) being module local. I think you risk too much having a global dictionary with potential conflicting rules/configurations (imagine a future with dozens of modules and a global dict getting uncontrollably out of hand). Staying module-local keeps things cleaner and more organized and reduces the risk of having Base conflicts. I don't think it's too much of hassle to load the Pycall module, set a Pycall.CONFIG value, then reload.

I also think we have to avoid using the .juliarc.jl file because users could easily copy and paste an old .juliarc.jl file into a new Julia version and mistakenly overwrite old CONFIGs or have compatibility issues.

I think in general, use of CONFIG should be discouraged in favor of programmatic defaults and good API design; my limited experience with PHP has made me strongly dislike the all-powerful php.ini file. Base.CONFIG should be tightly controlled and IMO, be tightly tied with command-line flags/arguments (they feel more natural for setting/overwriting global defaults if needed).

[JeffBezanson]

The best approach is to avoid configuration altogether. Having to call e.g. pyinitialize("path") might be annoying, but it is not as bad as having to set some configuration key before calling pyinitialize(). The second one is more mysterious.

I don't think setting an option and reloading a module will work, since the value would have to be stored somewhere globally in order to persist.

[quinnj]

With the .ini file idea, there would be a .ini file for each module (that needed one) that could sit in the package's folder. Though thinking more about it, that could get messy with Pkg.update() calls...

[StefanKarpinski]

This will be part of Pkg3:

https://github.com/JuliaLang/Juleps/blob/master/Pkg3.md#runtime-configuration

But can only be given at the project environment level, not globally, and not in packages.