Description
Right now there is only one "dialect" of the fmf files being tmt test files, while if we want to use fmf in other context, they would have an ambiguity if a fmf tree is supposed to be processed by tmt or another program. An example of this is tmt lint.
Proposal
Define a standard .fmf/plugins file which would be read as a requirements.txt file, e.g.
# .fmf/plugins
tmt
tmt-cmake @ git+https://github.com/LecrisUT/tmt-cmake@main
Fmf responsibility here would be just to:
- Check that the plugin requirements are satisfied
name and specifier- maybe
extras and marker
- ignore
url
- Print out a
requirements.txt of the unsatisfied plugins when executing cli
- Print out all the
.fmf/plugins as is (in case this will evolve later). Useful if the user would want to always install the plugins
Impact in tmt/testing-farm
- tmt would have to suggest adding a
.fmf/plugins file with tmt line
- testing-farm would check the
.fmf/plugins and if there is a package there that it does not recognize with python3dist() as pre-installed, then fail early
Description
Right now there is only one "dialect" of the fmf files being
tmttest files, while if we want to usefmfin other context, they would have an ambiguity if a fmf tree is supposed to be processed bytmtor another program. An example of this istmt lint.Proposal
Define a standard
.fmf/pluginsfile which would be read as arequirements.txtfile, e.g.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 in
tmt/testing-farm.fmf/pluginsfile withtmtline.fmf/pluginsand if there is a package there that it does not recognize withpython3dist()as pre-installed, then fail early