Clarify required packages handling and naming

[psss]

Seems like the required packages terminology might welcome some clarification and cleanup. When I was thinking a bit more about the required packages categories, I see group related to tmt implementation itself:

• essential_requires ... required for essential tmt functionality, e.g. /usr/bin/flock or bash
• plugin_requires ... needed by enabled step plugins, e.g. python3 for prepare.ansible

The rest seems to be closely related to tests:

• test_requires ... packages requires by tests themselves
• framework_requires ... test framework requires
• check_requires ... packages required by test checks

What about using the above-mentioned naming (or similar) to make the area more clear? It would be also good to clearly document how exactly the required packages are handled and when they are installed.

Originally posted by @psss in #4802 (comment)

[happz]

(Copied from #4802)

Yeah, seems like the required packages terminology might welcome some clarification and cleanup. When I was thinking a bit more about the required packages categories, I see group related to tmt implementation itself:

• essential_requires ... required for essential tmt functionality, e.g. /usr/bin/flock or bash
• plugin_requires ... needed by enabled step plugins, e.g. python3 for prepare.ansible

The rest seems to be closely related to tests:

• test_requires ... packages requires by tests themselves
• framework_requires ... test framework requires
• check_requires ... packages required by test checks

What about using the above-mentioned naming (or similar) to make the area more clear? I'd revert the last commit not to block this pull request and we could handle that in a separate one.

If we use the *_requires naming scheme, we would enter the world of pleonasms: BasePlugin.plugin_requires(), Check.check_requires(), TestFramework.framework_requires(), ... I believe it's obvious, so picking a name that could be same across all entities that can have requirements would be preferred by me. Test.requires() and Check.requires() would be much better than Test.test_requires() & Check.check_requires().

In that case I would also drop the essential bit then, as it kind of loses its necessity. /usr/bin/flock, for example, is not a requirement of tmt, it's a requirement of execute/tmt plugin, and bash is not required by anything, tmt expects it to be already installed. I guess we are just discussing the name for this method, as "essential" does not have clear meaning - "requirements of this entity" would be clearer.

How about we find a name for this "package-level requirements of this entity" method, and drop the "essential" category? Order 30 can be defined as "Installation of plugin requirements.", no need to involve any "essential" label.

[LecrisUT]

Same, the multiple *_requires is more confusing. The only distinction I care about is if it appears right after provision or as a normal requires/recommends. My preference is that the naming there would reflect the const variables for the order that we use, whatever that name may be.

Btw, why do we run the "essential requires" at prepare step? Wouldn't any other prepare step fail if it is injected before that, e.g. due to missing rsync, or is that yet another different requirement from the ones above?

[happz]

Btw, why do we run the "essential requires" at prepare step? Wouldn't any other prepare step fail if it is injected before that, e.g. due to missing rsync, or is that yet another different requirement from the ones above?

rsync is yet another special case, as tmt tries to install it if it's not available, transparently, when push() or pull() are invoked.

Yes, other prepare phases may fail if they happen before the installation of essential requirements, but that's why its order is documented, and well lower than the default order value. That gives us clear point when these packages are installed, while users can place their stuff before if they need to.

[psss]

In that case I would also drop the essential bit then, as it kind of loses its necessity. /usr/bin/flock, for example, is not a requirement of tmt, it's a requirement of execute/tmt plugin, and bash is not required by anything, tmt expects it to be already installed.

Ah, good point, bash is not even included... and flock belongs under plugins. Then yeah, let's call them just plugin requires to make the name more self explanatory.

Test.requires() and Check.requires() would be much better than Test.test_requires() & Check.check_requires().

Completely agreed. Maybe a short section Requirement Handling could be added, similar to Tree Handling describing briefly how these all play together? And glossary extended with those terms?