[feature] Add query interface to conan inspect

[samuel-emrys]

What is your suggestion?

I think it would be useful from a CI perspective to be able to easily extract information about a package from a conanfile.py. Currently, we have conan inspect, which gives some good information related to a package:

$ conan inspect . --format json
{
    "author": "<Put your name here> <And your email here>",
    "build_policy": null,
    "build_requires": null,
    "buildenv_info": null,
    "channel": null,
    "conf_info": null,
    "cpp": null,
    "default_options": {
        "shared": false,
        "fPIC": true
    },
    "deprecated": null,
    "description": "<Description of foo package here>",
    "exports": null,
    "exports_sources": [
        "CMakeLists.txt",
        "src/*",
        "include/*"
    ],
    "generators": [],
    "homepage": null,
    "license": "<Put the package license here>",
    "name": "foo",
    "no_copy_source": false,
    "options": {
        "shared": [
            true,
            false
        ],
        "fPIC": [
            true,
            false
        ]
    },
    "package_type": null,
    "provides": null,
    "recipe_folder": null,
    "requires": null,
    "revision_mode": "hash",
    "runenv_info": null,
    "settings": [
        "os",
        "compiler",
        "build_type",
        "arch"
    ],
    "test_requires": null,
    "tested_reference_str": null,
    "tool_requires": null,
    "topics": [
        "<Put some tag here>",
        "<here>",
        "<and here>"
    ],
    "upload_policy": null,
    "url": "<Package recipe repository url here, for issues about the package>",
    "user": null,
    "version": "0.1.0",
    "win_bash": null,
    "win_bash_run": null
}

But to extract the package name I currently have to do something like this:

export PACKAGE_NAME="$(python -c 'import subprocess; import json; result = subprocess.run(["conan", "inspect", ".", "--format", "json"], capture_output=True, text=True); data = json.loads(result.stdout); print(data["name"])')"

It would be useful if this was built into the interface so that it could be accessed something like:

conan inspect . --query name # returns 'foo'
conan inspect . --query version # returns '0.1.0'
conan inspect . --query default_options.shared # returns 'false'

I think that this would help make our CI scripts a bit more readable.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Thanks for your suggestion @samuel-emrys

I think this makes sense, and I think I recall it is not the first time this is requested.
I have considered the possibility to do the basic conanfile.py evaluation with some CLI or python API, but don't know if it would be too dirty/complex, we need to have a deeper look at this. Wouldn't be very high priority, but let's label as a valid feature and "look into" it to estimate the effort and possibilities.

[nmccrea]

I am able to do this qute nicely in v1.59 using conan inspect --raw. As in:

CONAN_PACKAGE_NAME=$(conan inspect . --raw=name)
CONAN_PACKAGE_VERSION=$(conan inspect . --raw=version)

We are using this in our CI scripts, exactly the use case OP mentioned.

The elimination of --raw in v2.0 is the very first problem I encountered when trying to upgrade and we haven't found a decent workaround yet. Until we do we may be stuck on 1.x.

[memsharded]

With #13716, from 2.0.5, Conan will be able to return name, version, evaluating the set_name and set_version as built-in, which was a gap here.

Still, we are not sure about a specific interface to extract 1 single attribute, this is kind of standard work in CI, and jq could greatly help with it, like for me the steps should be:

$ conan inspect . --format=json > inspect.json
$ NAME=$(jq .name inspect.json)

I think this approach is robust, simple, applicable to tons of other situations (every Conan command with a json output), generic and well known

[samuel-emrys]

jq does look like a convenient tool, and it would work well with linux, but it's additional overhead in setting up on a windows agent is frustrating. I think I'd probably be more inclined to deal with the overly verbose python than deal with an additional dependency. This is just a convenience function, but I think it does improve the friendliness of the CLI.

If you want this to be consistent across all interfaces, perhaps you could add a companion argument when --format=json is used for --query, so:

$ conan inspect . --format=json --query name

Or maybe this is just internally how --query works, so you still get the simpler interface to query any one parameter:

$ conan inspect . --query name # gets json and parses it for the query value

I'm not sure this is necessary across all interfaces, but the consistency is nice. There are certain output values that I suspect are more useful for direct evaluation on the CLI (inspecting package properties), and others that I suspect are much more valuable programatically (reasoning about the graph, build order, search, list, cache, etc).

[memsharded]

jq does look like a convenient tool, and it would work well with linux, but it's additional overhead in setting up on a windows agent is frustrating.

I work in Windows, jq is a single executable, download in 2 seconds (literal), put it in the path or in the current folder and works 😄 . It is in chocolatey too.

The problem of the "companion" --query argument for commands with json output is that it is basically requesting a re-implementation of jq inside Conan. Because things are not always simple first level dicts, the output of conan graph, conan install, conan create, will be a more complex json with nested levels. Even some elements of conan inspect are not simple strings either, but lists or other stuff. I feel that whatever we try to do will end as a poor, buggier and worse partial implementation of jq. So for this matter I am inclined to think that the separation of concerns and responsibilities is better. Conan should be focused on doing what it does well, its goals shouldn't include implementing something because it is inconvenient to install a (super popular and well known, we are talking 25k stars in Github) tool that solves that exact problem much better than Conan would ever do.

[memsharded]

Recall that as we fixed the commands output and the stdout is also clean now, t is also possible to pipe the commands, this works for me in Windows, in a oneliner:

$ conan inspect . --format=json | jq .name -r

[memsharded]

I have discussed this with the team. It seems there is a total consensus, we have fixed for 2.0.5 the major blocker that was the evaluation of the set_name() and set_version() methods for conan inspect, but the implementation of such query interface over a json won't be considered at the moment as built-in in Conan. Sorry that we cannot provide that inside Conan, but resources are limited and we need to focus, even if some things could seem convenient for users, the effort-value tradeoff is too much for us. We think that if such an interface is really convenient for some user, implementing a Conan custom command for it is very straightforward (because doesn't need to be as generic as a built-in, compromises can be made for your own org) we created a new API method for it, no need of external tools installation in different platforms, etc.

Closing this issue, thanks very much for the feedback!

[samuel-emrys]

No problems, it was just a convenience thing. Thanks for the consideration 🙂