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.
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