<div dir="ltr"><div><div>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.<br>
</div><div><br>A few observations/questions:<br>* 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.<br>
</div><div>* 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.<br></div><div>* 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?<br>
</div><div>* 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?<br></div><br></div>- Tim<br></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Jul 14, 2014 at 3:06 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If there are no comments or suggestions besides what has already been<br>
said, I'll keep the 5 step search path exactly as it is in 0.95. Please<br>
do comment if you have something to say. We're less likely to re-visit<br>
the issue in the future.<br>
<br>
Anyway, the second issue is whether we want automatic or explicit<br>
inheritance. In other words, do we want all of the 5 steps to be loaded<br>
in order, non-existing files being silently skipped, or do we want the<br>
first file in the search path to have to explicitly include others. Or<br>
do we want a mixed behavior (such as SWIFT_SITE_CONF and ./swift.conf<br>
both loaded automaticaly but not others)?<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, 2014-07-14 at 11:00 -0700, Mihael Hategan wrote:<br>
> Hi,<br>
><br>
> So, first, when I say "gone" that means "it's not there right now in<br>
> trunk". This is work in progress, and I was hoping to get feedback from<br>
> everybody, hopefully based on use cases and experiences. This change<br>
> brings an opportunity to re-visit some of the things we have and see if<br>
> they make sense in the new context and make the right long-term<br>
> decisions.<br>
><br>
> The first question is whether ~/.swift/swift.conf and ./swift.conf<br>
> should be explicitly in the search path, since SWIFT_SITE_CONF can do<br>
> both:<br>
><br>
> export SWIFT_SITE_CONF=~/.swift/swift.conf<br>
> export SWIFT_SITE_CONF=./swift.conf<br>
><br>
> Mihael<br>
><br>
> On Sun, 2014-07-13 at 20:02 -0700, Mihael Hategan wrote:<br>
> > Sorry. This discussion went a bit off. I apologize.<br>
> ><br>
> > Search path. There are some changes. Here are the details:<br>
> ><br>
> > 1. swift/etc/swift.conf is still there<br>
> > 2. SWIFT_SITE_CONF is still there. It makes good sense.<br>
> > 3. ~/.swift/swift.conf is gone. SWIFT_SITE_CONF does the same and is<br>
> > explicit. Can be added back.<br>
> > 4. ./swift.conf is gone for reasons of magicality. Can also be added<br>
> > back.<br>
> > 5. -config on the command line is still there.<br>
> ><br>
> > The fundamental difference is that there is no "if it's not there,<br>
> > ignore silently and continue" behavior and there is no automated<br>
> > chaining. The user has to say what they want. It's a one-time operation<br>
> > per file. Very likely less work than the actual contents of the file,<br>
> > but less error-prone. It's a choice. That of safety vs. convenience. We<br>
> > can bias either way and supplement with tools.<br>
> ><br>
> > We could and should discuss the merits of what has changed. It might<br>
> > help if we do it one issue at a time.<br>
> ><br>
> > Mihael<br>
> ><br>
> > _______________________________________________<br>
> > Swift-devel mailing list<br>
> > <a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
> > <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> Swift-devel mailing list<br>
> <a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
> <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
<br>
<br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br></div>