You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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 arequirements.txt
, i.e. PEP508, and parsed viapackaging.requirements
. So it may look like:Fmf responsibility here would be just to:
name
andspecifier
extras
andmarker
url
requirements.txt
of the unsatisfied plugins when executing cli.fmf/plugins
as is (in case this will evolve later). Useful if the user would want to always install the pluginsImpact:
The text was updated successfully, but these errors were encountered: