Quoting Luke Kanies <[EMAIL PROTECTED]>:
Okay, I've got them hooked together. Unsurprisingly, the script is
relatively hackish -- not much in the way of error checking, not at
all OO, etc. -- but it's functional, anyway.
That was quick :)
Notice there's no carriage return in the file; I tried putting an
escaped carriage return in the string, but I got a failure.
No escape sequences are allowed in mcfg strings; believe it or not this
wasn't to do with the difficulty of parsing, I actually started with
code to parse c-style strings, which you can see in other tools I've
written. The reason was to prevent you from doing exactly what you did:
ie putting literal file contents and commands into an mcfg
configuration. Note there are two independent issues: there's no
technical reason for not doing this, and the XML profile format
supports it entirely. However, for good practice usage, its quick but
its a bad idea. Use grplace or any templater, or just a repository
(reference the file like you did in your original example) and use the
profile for encoding high level decisions not the low level detail.
The important thing here is that it's correctly parsing the generated
XML and doing the appropriate work.
That is cool.
I haven't tried the "file.sudoers.mode = 'blah'" thing yet; that
seems somewhat cleaner because it would provide something that
resembled typing, but it would require that both the type and title
get duplicated on every attribute assignment, which is a step
backward, I expect.
This is just a question of syntactic sugar. I debated whether to allow
a construct like:
with foo.x {
# set properties of foo x
}
and opted against it until there was more evidence for its need. Theres
conflicting evidence for whether this is a good idea; easier and more
brief isn't always better, and in particular, when I worked as a Delphi
programmer, use of the with construct in Delphi was not welcomed. The
problem comes from shadowing, e.g. what does this mean:
x = foo;
You have to know all the enclosing with{} contexts to know what this
refers to, and you can easily end up assigning to the wrong thing, or
getting values from the wrong place without realising it. In
Delphi/Pascal, with is a source of bugs, hence it didn't make it into
the draft of the mcfg language.
The mcfg syntax is a bit clunky for Puppet, because it requires that
you type at least the name of every resource for every setting, and
it requires semicolons (although that could probably be optimized
out).
The semicolons are intentional too :) Clearer is better. You can't know
all the different types of editor and so forth people might want to
use, so allowing statements to be split over multiple lines is
important. If you don't require a statement separator, then it gets
quite difficult to tell the difference between line breaks and typos.
There are some features in Puppet's language that are missing in
this, like the ability to specify default values for all resources of
a given type (e.g., a default package type, or a default search path
for scripts), and a function that interprets ERb templates and
returns the results as a string (this is *really* useful for
server-side file generation, and it can look up variables in Puppet's
language). However, I understand that this is a different language
with different functionality. I will say that multiline strings are
wicked important and they're quite easy to parse.
For server-side file generation, use grplace or something else: that
is, generate the file using the profile. For the process to be simple
and transparent, it needs to flow pretty much straight down: specify,
generate, deploy. mcfg does specification, and putting code into
specification becomes a mess quite quickly; I believe the PAN guys
would agree.
Ed
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
