[Avocado-devel] RFC: Configuration by convention

[Cleber Rosa]

On Wed, Dec 04, 2019 at 03:52:40PM +0200, Plamen Dimitrov wrote:
> Hi all,
> 
> On 12/3/19 9:15 PM, Cleber Rosa wrote:
> >>> And since almost everything in Avocado is a plugin, each plugin section should
> >>> **not** use the "plugins" prefix and **must** respect the reserved sections
> >>> mentioned before. Currently, we have a mix of sections that start with
> >>> "plugins" and sections that don't.
> >>>
> >> So basically
> >>
> >> [vt]
> >>
> >> vt-related-option
> >>
> >> [vt.generic]
> >>
> >> generic-vt-related-option
> >>
> >> [runner]
> >>
> >> runner-related-option
> >>
> >>
> >> yes, the plugins section seems redundant as many parts are actually implemented as plugins.
> >>
> > Yes, agreed.  The "plugin" suffix can go.
> > 
> 
> +1 on this
> 
> >>> Reserved Sections
> >>> ~~~~~~~~~~~~~~~~~
> >>>
> >>> We should reserve a few sections as reserved for the Avocado's core
> >>> functionalities. i.e: main, plugins, logs, job, etc...
> >>>
> >>> Not sure here, it makes sense?
> >>>
> >> If we are to remove the "plugins." namespace then yes, we should reserve some names. At least "core" to indicate core options, or all above (plus perhaps some other core parts).
> >>
> > How can we tell if we have reserved *enough* sections?  If know that we
> > need a section such as "logs", and use it, this is a de-facto reservation.
> > What worries me is a preventive reservation because they will be probably
> > speculative.  In a programming language, reserved words have a use, and
> > thus variables and other statements can't use it.  But image a reserved
> > word that is never used...
> 
> I would suggest simply using the a single "core" keyword here. It is explicit
> and we always know that everything that is not "core" relates to some plugin
> with its unique suffix (e.g. "vt" above).
>

That may work, but may also lead to configuration entries that are rather
long because of the lack of specificity of the section name.  So, instead
of:

  [sysinfo.collect]
  enabled = True

We would have

  [core]
  sysinfo_collect_enabled = True

I'm not arguing against it, but just making it clear.  In fact, it may
even make things simpler wrt to the upcoming discussion on the Job
API.

> Sorry for not commenting further on my side, as a regular plugin developer that has
> used and adds some configuration, the most important thing I can say is that there
> probably isn't a developer that would object improved consistency of the way configuration
> is treated.
> 
> Plamen
> 

That's actually good feedback, thanks a lot!
- Cleber.