[augeas-devel] Who should ship lenses?

[David Lutterkort]

Hi Francis,

Thanks for bringing this up.

On Sat, 2011-04-02 at 12:43 -0400, Francis Giraldeau wrote:
> I think I remember one of the long term goal would be to let upstream
> projects appropriate their own lenses, and remove them from the augeas
> repository. There are pros and cons to this strategy:
> 
> Pros:
>   * Lens should better match the upstream conf in case of a syntax
>     change
>   * More distributed model, better scalability (crowd-sourcing)
> 
> Cons:
>   * Installing the related software would be required to edit it's file
>     syntax (ex: editing files in a chroot without augeas in that chroot)

That's not really a problem of lens distribution; if you want to modify
files using augeas you have to install augeas, no matter where lenses
come from ;)

>   * Who should own general lenses, like ini or shell lenses?
>   * Upstream may not be interested at all to manage lenses, lenses will
>     become spread in the universe
>   * Il will be harder to get uniform lenses and tree structures
>     conventions
>   * Upstream may not implements unit tests in their build systems for
>     the lens, which would require augeas

The big issue that having lenses upstream solves very elegantly is
version mismatch between the lens and the underlying config files. It
seems that that is much less of a concern than was initially thought;
and for now, I am perfectly happy having most of the lenses live with
Augeas, where people who understand the ins&outs of writing lenses can
look after them.

In my opinion, the best place for lenses is still upstream, assuming
that the upstream does maintain and test the lenses properly. If that's
not the case, it's better to keep the lens in the Augeas repo.

I know a few packages that ship their own lenses (libvirt, netcf) and
started a script to pull down their lenses and run their unit tests as
part of the augeas tests, but never integrated that properly with
Augeas' build system.

David