dub: should we make it the de jure package manager for D?

[H. S. Teoh]

On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
> On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
> > Why not YAML? It's cleaner than JSON and is very widely known.
> 
> YAML is just plain evil. It doesn't ignore whitespace.
[...]

It's funny. I used to think Python is evil for the same reason, but
after having played with it a little (mostly in SCons build scripts,
though, not full-fledged Python programs), I've come to actually like
it. It *is* rather refreshing to _not_ have those cascading '}'s
trailing every function body, taking up precious screen real estate. And
reindenting code doesn't require tedious checking to make sure those {'s
and }'s still line up as they ought.

I'd say that it's an acquired taste, at least for me. :)

But I've never used YAML, so I can't say whether or not I'd like it.

One thing I find lacking in these purported configuration file formats,
is the lack of built-in facility for cascading, and formatting long
values nicely.  In my own personal projects, I use a format that allows
cascading, in which the program first loads a base configuration, which
is then selectively overridden by subsequent configuration files
specified by the user, command-line arguments, or direct user input, of
which there can be arbitrarily many overlays. This is especially useful
in programs where you run many times, each time with mostly the same
settings as the previous time, just slightly tweaked. Instead of
retyping (or copy-n-pasting, or scroll history + edit) 50 different
settings each time, you put them into files containing 5-10 settings
each (in fact, one file for each variant of the same 5-10 settings, if
you're so inclined), and freely combine them in various ways, plus
specify a few on-the-fly settings on the command-line, say.

As for long values, I've always disliked the fact that almost all
formats provide a way to wrap them across multiple lines, but almost
none of them let you indent the result nicely without also changing the
value.  This is important for complex configuration formats that have
nested groups of settings. In my format, the syntax is specifically
catered for this use case, for example:

	# This is a comment
	value1 = "This is a very long value \
	         \split across multiple \
	         \lines."
	value2 = "A short value"

	module1 {
		# These values are in a nested scope, so they are
		# distinct from the settings above.
		value1 = "This is another long \
		         \value split across \
		         \multiple lines."
		value2 = "This is a value \
		         \with an embedded \   # a long value
		         \comment!"
	}

The \'s at the end of the line begin a continuation escape sequence that
spans until the first \ on the following line, thus allowing arbitrary
indentation. The resulting value is a concatenation of the stuff before
the first \ and after the second \. You can even place a comment in
between them, for documentation purposes.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL