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.
