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

[Mihael Hategan]

On Mon, 2014-07-14 at 20:04 -0500, Michael Wilde wrote:
> 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.

Ok. I'm assuming the intent was for this to always be loaded by swift if
the environment variable is present, no matter what the user says in
other places. It could be disabled if really needed by unsetting the
env. var.

> 
> 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.

Right. Although the user could include a site wide configuration, but
that would not closely match the intent of it (i.e. a site-imposed
setting). I think there is agreement here that this should stay, and
should be loaded after etc/swift.conf.

> 
> 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.

I think that there is agreement that at least swift/etc/swift.conf (with
sufficient information to allow simple local execution) and
argv["-config"] and then SWIFT_SITE_CONF are all needed, so I think that
answers the question of whether there should be a search path.

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

Sorry. Not currently. This was one of the things that was under
question. So should we still have it? Should we instead leave it as an
option to be included by the user from a more specific configuration
file?

This was in a sense intended as a site-wide configuration (for a given
user), so I felt, perhaps wrongly, that it did overlap with
SWIFT_SITE_CONF. 

[...]
> 
> 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.

3x the problem until recently: sites, tc, and config.

I personally didn't care. I wrote a simple run script, so I also didn't
have to type the swift script name every time. Though in both cases, I
just type once, and then use the command line history.

> 
> 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.

That's correct. Though it would be a less frequent problem, since it is
one file vs. many. Same for ./.bashrc, ./.emacs. I agree that ~/. files
are standard practice. Implicit files in the current directory, less so,
with, perhaps the exception of make.

However the argument was an example that was trying to illustrate that
silent automated choices are prone to subtle yet hard to troubleshoot
problems. The benefits may outweigh the risk. I don't really know. I'd
generally go with safety if it's only slightly less costly than the lack
of it. But it's personal preference.

>  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

This is easy to do by >include ${env.PWD}/swift.conf< in
~/.swift/swift.conf, with no addition of a new property.

But see Tim's comments about including it from PWD vs. where the swift
script is.

> 
> 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".

I think both etc/switf.conf and SWIFT_SITE_CONF are suitable for this.
This is not a statement against ./swift.conf, just an observation.

Mihael