This is primarily for tmt but it doesn't hurt to implement it as a standard here.
Issue: Similarly to how tmt expanda upon an fmf tree, the tree might not be fully valid depending on how it is parsed, e.g. w.r.t. schema validation.
Approach: Along with .fmf/version, a .fmf/plugins could be optionally parsed. The format would be similar to that of a requirements.txt, i.e. PEP508, and parsed via packaging.requirements. So it may look like:
This is primarily for
tmtbut it doesn't hurt to implement it as a standard here.Issue: Similarly to how
tmtexpanda upon an fmf tree, the tree might not be fully valid depending on how it is parsed, e.g. w.r.t. schema validation.Approach: Along with
.fmf/version, a.fmf/pluginscould be optionally parsed. The format would be similar to that of arequirements.txt, i.e. PEP508, and parsed viapackaging.requirements. So it may look like:Fmf responsibility here would be just to:
nameandspecifierextrasandmarkerurlrequirements.txtof the unsatisfied plugins when executing cli.fmf/pluginsas is (in case this will evolve later). Useful if the user would want to always install the pluginsImpact: