[augeas-devel] Language revamp

[Bryan Kearney]

My head hurts. Comments below:

David Lutterkort wrote:
> 
> Some explanations:
>       * A 'module' is a simple grouping of names; for now, I don't think
>         there's a need for nesting modules. It's just a way to keep
>         names separated (so that you can have a Sshd.lens and a
>         Hosts.lens)

As long as I can say that file X and Y and Z are all types of ini, or 
properties, etc then I am fine not having nested modules. It does seem 
like there is some basic gammer (words, blank lines, etc) that everyone 
will share.


>       * String literals are enclosed in "", and regexps in //; most of
>         the lens combinators look the same as in the present syntax, but
>         I'd like to extend some of them to also work for strings and
>         regexps so that you can say 're1 . re2' for the regexp that
>         matches the concatenation of re1 and re2. Similar for 're1 |
>         re2' and concatenating strings
>       * The 'del' lens is new; deleting entries from the input (i.e.,
>         not including them in the tree) now needs to be more explicit,
>         so that a default value can be included - the default was
>         previously part of the token definition.
Does this mean that if a read a file in with comments, and write it out 
the comments are lost?
>       * The 'let' creates a new name for something. Functions need to
>         declare their arguments, and the types of their arguments plus
>         the return type; the 'let sep' says "sep is a function which
>         takes a string and returns a lens"

I will be honest.. I dont know why I need the first sep function in the 
example. What value is it buying me? The older syntax seemed closer to 
an BNF, but I dont know if a pure BNF gives enough data to be 
bi-directional.

>       * Names need to be defined before they can be used; this also
>         precludes recursion (allowing recursion would make it possible
>         to write down lenses that process context-free languages, not
>         just regular ones; that leads to a whole host of problems best
>         left to some point in the future)
> 
> I also want to add a simple unit test facility, so that you can say
> right in your .aug file something like
>         test Hosts.lens put
>           "127.0.0.1 localhost"
>         after
>           rm /0
>         = ""
> with the general structure "test LENS put S after COMMANDS = S'" where S
> and S' are strings and COMMANDS is a list of augtool-like commands to
> manipulate the tree. The test would parse S into a tree, run COMMANDS on
> it and check that the result of turning the tree back into a string is
> S'.

any reason to not make it seperte, prehaps part of a dev package?

> 
> The stickiest bit about all this is how to deal with mapping files into
> the tree, and how to indicate what Augeas should do by default (e.g.,
> when augtool starts up) For now, the 'let files' in the above example
> says "apply the lens LENS (defined on the previous line) to the contents
> of file "/etc/hosts" and put the result into the tree under
> "/system/config/hosts". I am not entirely clear how that should work
> with globbing (like pam.aug does right now), and if files need to be
> created (think of creating a new .repo file when you create a brandnew
> subtree under /system/config/yum) 

I really dont like the idea of the config tree being different from the 
actual file system. I understand that it would promote portablity 
between layouts, but if I am workning on file system editing.. I think 
it would improve readability to see the actual hierarchy.

So.. on start up.. I could see two models:

1) Could you cache the mappings at startup, and then lazily read read in 
the grammers? So... you would only read in the grammer for pam when I 
access something under /system/config/pam (well.. for me ideally /etc/pam)

2) I could see a model where you "open" the file, and then use the tree 
syntax relative to that root. This is probably better for the api, but 
something like
edit /augeas/files/etc/hosts
set 10000/ipaddr = 192.168.0.1
set 10000/canonical pigiron.example.com
clear /10000/aliases
commit


> 
> Eventually, I'd also like to be able to process include directives in
> files through some special lens, so that you can say "take the string
> that match this regexp, read the file with that name, process it with
> lens X and put the resulting tree here in the global tree"
> 
> The 'autorun Hosts.apply' is an attempt to make it explicit what Augeas
> should do in standalone mode (e.g., when augtool is started without any
> special instructions of what files to process - you can't do that right
> now, but I'd like to add that) The 'autorun Hosts.apply' says "Remember
> the Hosts.apply lens on some internal list, and if you don't know what
> else to do, run all the lenses from that list"
> 
> Since this is going to be a good chunk of work, it'll be a while before
> it's all implemented. I'd appreciate any comments, especially on whether
> this would be a change for the better, whether you think writing file
> format descriptions for Augeas will become more understandable, easier,
> quicker, more maintainable etc.
> 


What about specific validtions? So.. I know that in hosts the ipaddr 
should be in a known format. It seems like I could support this now, is 
this correct?