[augeas-devel] Lens compatibility (ticket #295)

David Lutterkort lutter at redhat.com
Tue Aug 14 18:11:34 UTC 2012


Hi,

I think this topic is complicated enough to deserve a thread on the
mailing list ;)

There's two things floating around right now that cause backwards
compatibility headaches: (1) the change to the square lens and (2) a few
changes to lenses (handling of export/unset in Shellvars, handling of
exclude in Yum)

I doubt that the change to the square lens will cause much headaches -
as far as I can tell, it's only used in the lenses we ship, and we can
fix those places up. In addition, it doesn't lead to tree changes, and
if somebody would have a lens that uses the old square, loading that
lens will fail loudly.

The other kind of change is more problematic, since it changes the tree;
e.g. for Shellvars, we are discussing changing

  { "export" = "VAR" }

to

  { "export" { "1" = "VAR" } }

I don't like the idea of just shipping all old lenses, since that will
quickly become a maintenance nightmare (if there is a bug in Shellvars
that does not require a tree change, do we fix that in old lenses ?)

Generally, people will also want that the tree-breaking change in
Shellvars is hidden from them, while they probably will want the
latest/newest lens for other files (e.g., fixes to quoting in Xml)

One idea would be to maintain specific variations of lenses using a
conditional:

        let lns = match shellvars_variant with
           "split_exports" -> lens_with_export_splitting
         | _               -> old_lens
        
We could then further help users by maintaining a config.aug with
entries like

        module Config
        
          let shellvars_export = "split"
          let yum_exclude      = "split"

and say 'match Config.shellvars_export with ...' in the above example.

We could then ship different versions of the config module,
corresponding to each version of augeas; we'd have a config.aug that
reflects the latest greatest in lenses, and a config_x_y_z.aug that
makes lenses behave as they did in version x.y.z. By default. config.aug
will be loaded; if users want one (or some) lenses to behave
differently, they can copy config_x_y_z.aug into their lenses directory,
or create one that only sets some lenses to behave like in the old days.

I am not entirely happy with the impact this will have on testing, since
we'll have a lot more variations of lenses that need to be tested.

Thoughts ?

David

BTW, I have a very old patch floating around that adds a match construct
to the lens language.





More information about the augeas-devel mailing list