[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