[question] Need clarification on python_requires best practices

[duffsterlp]

What is your question?

Hi conan community! I'm trying to understand the best practices around python_requires including other python_requires.

We're in the process of transitioning from conan 1 to conan 2.

In the conan 1.66 documentation, I see the following:

python_requires can python_requires other recipes too, but this should probably be limited to very few cases, we recommend to use the simplest possible structure.

In the conan 2.X documentation, I see the following:

Even if python-requires can python_requires transitively other python-requires recipes, this is discouraged. Multiple level inheritance and reuse can become quite complex and difficult to manage, it is recommended to keep the hierarchy flat.

We have components that include repoA as a python_requires. It is desired for repoA to include repoB as a python_requires.

Does this conflict with any of the best practices above? I can get into the reasons why we're doing this but first wanted to understand whether the overall flow was recommended or discouraged and why.

For the conan 2 docs, what does Even if python-requires can python_requires transitively other python-requires recipes mean? Does it mean compA using repoA as python_requires using repoB as python_requires using repoC as python_requires or the fewer chain of components?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @duffsterlp

Thanks for your question.

Does this conflict with any of the best practices above? I can get into the reasons why we're doing this but first wanted to understand whether the overall flow was recommended or discouraged and why.

It is mostly discouraging trying multiple inheritance, this is, the usage of python_requires_extend for transitive python_requires, or even from multiple, not transitive python_requires.

This is because this inheritance is not the classic Python inheritance, it is a "dynamic" or "forced" one, because it cannot be evaluated at Python parsing time by Python, as the dependencies are not even in disk the moment a recipe is first evaluated. So Conan needs to resolve the dependency, load the base class, and then inject that base class into the base classes of the consumer. But that doesn't evaluate like the Python built-in inheritance, and it can be confusing in case of multiple inheritance, because the final result can be different to the Python one. Also, the attributes might not be always overriden as expected (sometimes the init() method is necessary)

That doesn't mean that transitive python_requires are completely forbidden, there are still not encouraged, but not as discouraged as the transitive inheritance with python_requires_extend

For the conan 2 docs, what does Even if python-requires can python_requires transitively other python-requires recipes mean? Does it mean compA using repoA as python_requires using repoB as python_requires using repoC as python_requires or the fewer chain of components?

It means that a package that is already a package_type = "python-require", even if it can contains itself a python_requires to other recipe, it is not recommended in general, and it is better to try to keep it simpler and flat if possible. It is implemented, it works up to the limits mentioned above with the inheritance and python_requires_extend, but it isn't necessarily great for all cases. Specially, for users using that python-requires, the functionality spread across more than one recipe is generally more difficult to understand and use correctly.