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

[Michael Wilde]

On 7/14/14, 1:00 PM, Mihael Hategan wrote:
> The first question is whether ~/.swift/swift.conf and ./swift.conf
> should be explicitly in the search path, since SWIFT_SITE_CONF can do
> both:
>
> export SWIFT_SITE_CONF=~/.swift/swift.conf
> export SWIFT_SITE_CONF=./swift.conf
This variable was intended specifically for shared site definitions, to 
be provided by the group that administers Swift on the site (eg, like 
the RCC team), for use by all Swift users at the location.

If its value can only be a single filename, it can not serve this 
site-wide role in addition to the two alternative roles you show above:  
personal settings (~/.swift/swift.conf), and run-specific settings 
(./swift.conf). This variable can only serve one of these three roles.

But I don't think that this is the first question.  The first question 
is, should we have a search path for conf settings, and if so, what 
should it be.

You indicated however that ~/.swift/swift.conf remains in use for 
personal settings. That's good.

So the sole difference in property search path between 0.95 RC6 and 
trunk is that trunk no longer reads a property file by a fixed name from 
the current directory in which swift is run.

0.94 had:

swift installation
user
-config
command-line options

0.95 had:

swift installation
site-wide (new)
user
script (./) (new)
-config
command line

trunk has:

swift installation
site-wide
user
-config
command line

So the first point to discuss is in fact do we retain or remove the 0.95 
notion that properties that apply to a specific script can be placed 
alongside the script with no additional arguments on the swift command. 
Because that is, from considerable experience, the way most users use 
swift. Ive been creating a .cf file and specifying "-config cf" for many 
many years. Its just a question of whether virtually every swift 
invocation will continue to need to specify -config or not.

If the argument is that the user might mis-spell the name of the 
./swift.conf file, and perform a run with differet properties than were 
intended, I think thats a weak argument for removing this feature.  The 
user could just as easily mis-spell ~/.swift/swift.conf. An emacs user 
could mispell ~/.emacs or ~/.bashrc and the intended file would also be 
silently ignored. But there's a strong precedent for implicitly assumed 
config filenames in a variety of locations, and I think ./swift.conf 
calls into that same category.

One option is to add a property that specifies whether a default 
per-script config file is read.  This would be typically then specified 
by the user (or the tutorial setup) in ~/.swift/swift.conf. E.g.:
   perScriptConfig: ./swift.conf

If we need to keep specifying -config, I can live with that.  I'm more 
concerned that, in swift tutorials, simple things be simple. I like the 
simplicity of saying "swift part06.swift".

- Mike