[bug] "--raw <attribute>" still checks "python_requries"

[tharilya]

Hi,

I think ran into 'nearly the same' issue, like #5656 & #5702. This time with "python_requries".

Usecase:
I want to read the "name" and the "version" attribute of a conan-file without downloading / having issues with the dependencies. So I tried it with the "--raw" argument. But in case of dependencies of python-requires, I get errors.

Are these intended?

Environment Details (include every applicable attribute)

• Operating System+version: Linux ba53e1572d47 4.9.184-linuxkit #1 SMP Tue Jul 2 22:58:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
• Compiler+version: nothin selected
• Conan version: Conan version 1.21.1
• Python version: Python 3.7.5

Steps to reproduce (Include if Applicable)

(environment is the docker-container from conan-io gcc9

1. start the docker-container
2. create a new package
3. somehow init default files (e.g. with "conan install .")
   3.1. conan inspect . --raw name works at this moment
4. add the python_requires to the imports
5. add a non existing package as "python_requires"
6. try to get the "name" with the inspect --raw command

docker run -it --rm conanio/gcc9
conan new a_pkg/1.33.7@aUser/aChannel
conan install .
conan inspect . --raw name
sed -i '2i from conans import python_requires' conanfile.py
sed -i '3i python_requires(\"non-existent/version@user/channel\")' conanfile.py
conan inspect . --raw name

Logs (Executed commands with output) (Include/Attach if Applicable)

Log-Msg:

conan@ba53e1572d47:~$ conan inspect . --raw name
non-existent/version@user/channel: Not found in local cache, looking in remotes...
non-existent/version@user/channel: Trying with 'conan-center'...
ERROR: Error loading conanfile at '/home/conan/conanfile.py': Unable to find python_requires("non-existent/version@user/channel") in remotes

[memsharded]

Hi @tharilya

The case of python_requires is different, specially the ones that you are using. A recipe cannot be evaluated at all if the python_requires are not evaluated. As you might extend/inherit the recipe, you really need to fetch, parse, and apply that other recipe, in order to see the current one.

Please provide an example of a python_requires that actually exists. Does in that case affect the output?

Also note that the python_requires have changed syntax: https://docs.conan.io/en/latest/extending/python_requires.html This might help a bit to alleviate some problems, but still you should consider them as part of the recipe, not as a "library" dependency, so they should exist and be available in order to be able to use/inspect/consume a recipe.

[tharilya]

Hi @memsharded

It's working with an existing python_requires

• The behavior is the same with the "new" and "old" syntax of using python requires as the following examples are showing

example of existing python require (everything is working, as written above)
Example 1 (old syntax)

conan new a_pkg/1.33.7@aUser/aChannel
conan install .
sed -i '2i from conans import python_requires' conanfile.py
sed -i '3i python_requires(\"pybind11/2.2.2@conan/stable\")' conanfile.py
conan inspect . --raw name

Example 2 (new syntax)

conan new a_pkg/1.33.7@aUser/aChannel
conan install .
sed -i '16i\ \ \ \ python_requires = \"pybind11/2.2.2@conan/stable\"' conanfile.py
conan inspect . --raw name

Not working with non existent ones ...

Is this behavior intended?

If no, here is the complete terminal from the docker-container:

Steps to reproduce:

docker run -it --rm conanio/gcc9
conan new a_pkg/1.33.7@aUser/aChannel
conan install .
sed -i '16i \ \ \ \ python_requires = \"non-existent/version@user/channel\"' conanfile.py
conan inspect . --raw name

Complete-Log from Docker-Container:
(after docker run was executed ...)

conan@3adbe2f7053d:~$ conan new a_pkg/1.33.7@aUser/aChannel
File saved: conanfile.py
conan@3adbe2f7053d:~$ conan install .
Auto detecting your dev setup to initialize the default profile (/home/conan/.conan/profiles/default)
CC and CXX: /usr/bin/gcc, /usr/bin/g++
Found gcc 9
gcc>=5, using the major as version

************************* WARNING: GCC OLD ABI COMPATIBILITY ***********************

Conan detected a GCC version > 5 but has adjusted the 'compiler.libcxx' setting to
'libstdc++' for backwards compatibility.
Your compiler is likely using the new CXX11 ABI by default (libstdc++11).

If you want Conan to use the new ABI for the default profile, run:

    $ conan profile update settings.compiler.libcxx=libstdc++11 default

Or edit '/home/conan/.conan/profiles/default' and set compiler.libcxx=libstdc++11

************************************************************************************



Default settings
        os=Linux
        os_build=Linux
        arch=x86_64
        arch_build=x86_64
        compiler=gcc
        compiler.version=9
        compiler.libcxx=libstdc++
        build_type=Release
*** You can change them in /home/conan/.conan/profiles/default ***
*** Or override with -s compiler='other' -s ...s***


WARN: Remotes registry file missing, creating default one in /home/conan/.conan/remotes.json
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=gcc
compiler.libcxx=libstdc++
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]

conanfile.py (a_pkg/1.33.7): Installing package
Requirements
Packages

conanfile.py (a_pkg/1.33.7): Generator cmake created conanbuildinfo.cmake
conanfile.py (a_pkg/1.33.7): Generator txt created conanbuildinfo.txt
conanfile.py (a_pkg/1.33.7): Generated conaninfo.txt
conanfile.py (a_pkg/1.33.7): Generated graphinfo
conan@3adbe2f7053d:~$ conan inspect . --raw name
a_pkgconan@3adbe2f7053d:~$ sed -i '16i \ \ \ \ python_requires = \"non-existent/version@user/channel\"' conanfile.py
conan@3adbe2f7053d:~$ conan inspect . --raw name
non-existent/version@user/channel: Not found in local cache, looking in remotes...
non-existent/version@user/channel: Trying with 'conan-center'...
ERROR: Error loading conanfile at '/home/conan/conanfile.py': Unable to find 'non-existent/version@user/channel' in remotes
conan@3adbe2f7053d:~$

[memsharded]

Yes, totally expected.
As commented above, python_requires are not a normal library "dependency". As they can become part of the current recipe itself, it is necessary that they exist and are fetched to the local cache, so they can be parsed and interpreted. They are part of the current recipe. You cannot inspect or do anything with a a recipe without resolving first its python_requires.

So yes, I would say this is not a bug, it is expected behavior.

[tharilya]

Ok, thank you for the explanations and the fast response.

Kind Regards