[Swift-devel] Issues to resolve for the 0.96 config mechanism

[Mihael Hategan]

On Mon, 2014-07-14 at 21:09 -0500, Michael Wilde wrote:
[...]
> We could add properties that you could specify in ~/.swift or higher: 
> e.g., noSwiftConfFile, noSwiftScriptFile, etc.

I believe that there is a bit of technical difficulty there. A loaded
configuration is only fully defined when all the files have been loaded
(to allow all overrides to happen). These options would only be
available after all the files have been read, at which point the
decision of what was read had already been made.

It may be possible to define specific semantics for these options. For
example that they would apply as soon as the line is parsed, but,
again... technically difficult and the different classes of properties
raise some flags in my head.

[...]
> 
> so we have this implicit search path by default:
> 
> releaseConf=$SWIFT_HOME/etc/swift.conf
> siteConf=$SWIFT_SITE_CONF
> userConf=$HOME/.swift/swift.conf

While we're at it, but not worth a long discussion, should we have a
directory (.swift) for what is essentially a single file instead of
~/.swift.conf?

> runConf=$PWD/swift.conf
> 
> and these command line options:
> 
> -config
> -specific-properties

OK. Sounds reasonable. Combined with logging of the list of files used,
and the final property list with location for each one of them, this
should make troubleshooting easy.

I'd say -listconfig should only list the files used and state that a
full list of properties is available in the log file. This is to make
the output of -listconfig manageable and take care of the case where
users would not have otherwise checked the log.

> 
> To allow the default search path to be overridden on the command line, 
> we can permit:
> 
> -config file1:file2:...:fileN  # use these config files to replace runConf

This is equivalent to including file2...fileN from file1 . I'd vote
against having features that do what can be reasonably done by existing
features.

> -reconfig file:file2:...:fileN # use these config files to replace all 
> implicit config (including Swift's built-in defaults)

I think that this can also be achieved by a combination of -no*Conf and
-config + includes, so maybe we want to leave it at that? Makes both
testing and documentation simpler.

> 
> -noReleaseConf  -noSiteConf -noUserConf -noRunConf # use these flags to 
> remove implicit config files from config path

I think these address Tim's question about disabling configs quite well.

[...]

Mihael