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

[Michael Wilde]

I sent an earlier reply with having seen all the latest posts to this 
thread.
This reply tries to catch up - sorry!

On 7/14/14, 4:29 PM, Mihael Hategan wrote:
> Thanks. Inline...
>
> On Mon, 2014-07-14 at 15:57 -0500, Tim Armstrong wrote:
>> I think the implicit versus explicit thing is a matter of taste; that said,
>> as a personal preference it seems more elegant and convenient to have a
>> powerful but explicit include mechanism so that there's an easy and obvious
>> way to include alternative files at any stage in the process.
>> A few observations/questions:
>> * As a user I'd find it really surprising that the implicit ./swift.conf
>> still is in effect when I provided an explicit command line config.  I'm
>> not aware of any other systems that behave like this.
> That seems to be what happens in 0.95. I agree that the behavior is a
> little surprising.
>
> We could:
> - have the value of -config replace ./swift.conf in the search path,
> while keeping everything else unchanged
I agree - that would be good, and better than the current 0.95 behavior.

> - not have ./swift.conf in the search path
> - keep it as is in 0.95, but print out a message that both are being
> used
>
>> * If you invoke a Swift script from another directory, does the config file
>> in your current directory or the script directory take effect?  It seems
>> counterintuitive to me that you would have to cd into the script directory
>> when you're already explicitly giving the path to the Swift script.
> In 0.95 it is my understanding from reading the code that it would be
> the current directory. I suspect this is a simple oversight. Both the
> "new configs" are young code, and these things happen.
>
>  From what Mike was saying, and unless folks disagree, I would think that
> it should use swift.conf in the swift script directory.
I think it would be better to expect swift.conf in the current directory 
of the swift command.
The script may be remote; the cwd is where the user will be "working" 
and creating run directories, and its where the properties for the 
execution of the requested script would more conveniently placed.
>
>> * Is there a way I can temporarily disable a config file on the search
>> path, beyond moving the file or overriding all of the keys?  If so, is this
>> method discoverable to users?
> Not with any of the pre-trunk schemes. With explicit inheritance it
> would be a matter of commenting out an included file (and maybe
> additionally adding includes to any chained includes from the skipped
> file). I would say this is pretty obvious and therefore trivially
> discoverable.
>
> It could be possible to have the config search path be defined by the
> user, in a spirit similar to $PATH, but that might be pushing things too
> far.
We could add properties that you could specify in ~/.swift or higher: 
e.g., noSwiftConfFile, noSwiftScriptFile, etc.
(Ive not given any thought to these actual names, though). Ive suggested 
another property-affecting-property in a prior response, and these would 
have a similar role. At the risk of making the config mechanism still 
more complex for the purpose of making it more tailorable to individual 
preference.
>> * If ./swift.conf is meant to correspond to a particular Swift script,
>> would it make more sense to have the config name match the script name?
> That's a thought. Maybe. The consequences would be that you would need
> to re-name configuration files if you use them with another script and
> you would need to have multiple copies/links if you have multiple swift
> scripts in the same directory.
I think not, again for the reason above. ./swift.conf is more specific 
to the task the user istrying to perform than to the specific script 
being used.
>
> On the topic of includes, what do you think about specifying the config
> as a pragma directly in the swift script?
I could see that being useful on occasion to bind specific behavior to a 
script, but its yet another set of specs and philosophies to wrestle with.

I'd vote for holding off on discussion of this pragma aspect until we 
get to a consensus on the current points in this thread.

so we have this implicit search path by default:

releaseConf=$SWIFT_HOME/etc/swift.conf
siteConf=$SWIFT_SITE_CONF
userConf=$HOME/.swift/swift.conf
runConf=$PWD/swift.conf

and these command line options:

-config
-specific-properties

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

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

If in addition you leave in the include facility, I think all options 
are possible, and there's a reasonable rationale and logic to the process.

It does make testing quite a challenge; documentation should not be too 
bad provided we dont uncover weird cases.

Usability should be good, if we mostly leave things alone and use either 
./swift.conf or -config oneFile

Mike

>
> Mihael
>
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel

-- 
Michael Wilde
Mathematics and Computer Science          Computation Institute
Argonne National Laboratory               The University of Chicago