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

[Dominic Cleal]

On 14/08/12 19:11, David Lutterkort wrote:
> 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)

There are a few cases of type (2), but they're all very small changes to
lenses and trees.  They'll be much easier to handle with a conditional
than say, a full redesign of a tree... we'll need to be careful to draw
a line somewhere.  If we don't, then your question of fixing bugs in old
copies of lenses will equally apply to conditionals.

> 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.

It's this config mechanism that I'm uncomfortable with.  It seems to me
that we need something in the API that applications would use to
indicate their expected configuration rather than config through files.

Using files sounds like more work for a sysadmin and not as easy for an
application dev to make use of, as they'd have to set up a directory,
config file, change the include dirs etc.

-- 
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113