python requires with alias

[jgsogo]

Changelog: Fix: Resolve aliased packages in python_requires

• closes python_requires does not work with alias recipes #3920
• add test: alias with alias
• add test: alias with python_requires
• closes Gather information about transitive python_requires for graph output #4011 through Feature/fix py requires alias jgsogo/conan#7

[jgsogo]

I would want to use here the ConanFileLoader class, but it requires a python_requires member (and it is where I am!), see instantiation in conan_api.py here:

        python_requires = ConanPythonRequire(self._proxy, resolver)
        self._loader = ConanFileLoader(self._runner, self._user_io.out, python_requires)

[memsharded]

I think I'll prefer to really have an injected loader object into PythonRequires (yes, runtime cycle between objects).
We could make ConanFileLoader be the one that really instantiates PythonRequires object, passing a referent to itself to it.

This can't go to 1.9.2, a bit risky in my opinion.

[memsharded]

As commented previously, I think this needs architectural changes.

I think I'll prefer to really have an injected loader object into PythonRequires (yes, runtime cycle between objects).We could make ConanFileLoader be the one that really instantiates PythonRequires object, passing a referent to itself to it.

[jgsogo]

I'm having a look at this again, and it is not immediate. python_requires needs the module at the conanfile path, not the ConanFile class itself, and the loader doesn't retrieve the module. So it is not just a cosmetic change (and the runtime cyclic dependency), it requires modifying the API of the loader.

I think it is worth a different architectural PR, maybe creating the ConanPythonRequire inside ConanFileLoader as you said, but then we need to think why the first one needs the proxy, client_cache, remote_manager and registry... I think those are too many members to be inside the loader.

Please, review again (and consider merging)