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

Mihael Hategan hategan at mcs.anl.gov
Mon Jul 14 16:29:32 CDT 2014


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

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

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

On the topic of includes, what do you think about specifying the config
as a pragma directly in the swift script?

Mihael





More information about the Swift-devel mailing list