Merge fmf and python3-fmf packages

[LecrisUT]

We have 2 variants:

• merge fmf into python3-fmf
  • More standard python package format
  • Does not require %pyprovides
• merge python3-fmf into fmf
  • More inline with tmt package format
  • Can python3-fmf Obsoletes: fmf when fmf is still the "main package"?

Which version should we go with?

Depends-on: #202

[lukaszachy]

Hard to tell:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_mixed_use_packages
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_library_naming

Is fmf more in 'ansible' vs 'python library' use case?

[LecrisUT]

By ansible I guess you mean that it's its own ecosystem. I think tmt can fit into that, but fmf I think it's more basic like any other dependency in tmt. Indeed right now the 2 projects are very tightly linked, but I think this format has the potential to spread a bit further.

For example I find it very useful in scientific programs where you typically run hundreds of simulations that change only a few parameters, and the current tools that they use to "automate" this will make me want to keep a bottle of bleach near me for my eyes.

[lukaszachy]

Sorry, I should quoted from the packaging guidelines:

A Python library is a package meant to be imported in Python, such as with import requests. Tools like Ansible or IDLE, whose code is importable but not primarily meant to be imported from other software, are not considered libraries in this sense.

So I think 'fmf' is more "library" while 'tmt' is more "application". If I read guidelines correcty it means that 'fmf' should end up as 'python-fmf' component and building 'python3-fmf'. Or?

[LecrisUT]

So I think 'fmf' is more "library" while 'tmt' is more "application". If I read guidelines correcty it means that 'fmf' should end up as 'python-fmf' component and building 'python3-fmf'. Or?

Yeah, that is pretty much my gut instinct. Renaming fmf.spec -> python-fmf.spec would be a bit more involved though.