[question] Conan 2.x - Store conan create json output directly in conan package

[Jannis1994]

What is your question?

Hello together,
in the past we used the conaninfo.txt file for checking dependencies. Now in Conan2 I saw it is better to use the json output of conan create as some details are not in conaninfo.txt anymore (Reference: #16763).
For instance I am missing:
[full_settings]
[full_options]
[recipe_hash]

I only get [options] and [requires]

So I used the following command:

conan create . -o *:variant=$variant -o *:adg_compatibility=$adg_version --user test -f json --update > conan_info.json

My question would be now, how can I add this conan_info.json file to conan package after already creating it?
Is this only possible with the metadata option or is there something similiar to conaninfo.txt.

Using the conanfile.py package method and taking it from the recipe folder was also not possible without errors.
One idea I also thought of was executing the conan create steps manually but then it is not a one-liner anymore.

Best regards,
Jannis

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @Jannis1994

Thanks for your question.

Yes, at this moment that json can only be added to the package metadata after the package has been created.
Note that the conan create could also have a --build=missing, or even --build=*, and it will build not only the current package, but also the dependencies. But that json file that you are capturing from the command cannot be built after the dependencies have been built first, so it is kind of a chicken and egg problem, if the end goal is to have some file stored inside every package that is being built.

This is the reason we are working to add a new capability to conan, see: #17203

The feature is called like sbom feature, but note that the graph.json created by conan commands is nothing but a complete graph bill of materials. It is possible that we will rename that feature to be more generic.

One of the key points for that feature is that every package should create the manifest/graph.json/sbom of itself, that is, including its subgraph of dependencies, and computing that subgraph explicitly is not available yet in Conan. But #17203 is adding that capability, so the idea is that creating and storing such file is doable, either directly in recipes, or in the new sbom plugin.

[Jannis1994]

Hi @memsharded thanks for your quick answer.
Then I will look for another way. Just to quickly clarify, the reduced output in conaninfo.txt is right?
There is nothing I am missing?

Old conaninfo.txt in Conan1.X:

[settings]


[requires]
    baseimage/24393_594_1

[options]
    adg_compatibility=50.1.1
    variant=GEN3

[full_settings]


[full_requires]
    baseimage/24393_594_1@test_channel/stable:4699249c164c74520477d3086cedd40fd03

[full_options]
    adg_compatibility=50.1.1
    variant=GEN3
    baseimage:adg_compatibility=50.1.1

[recipe_hash]
    382be077743eecf5591423ab9

[env]

New conaninfo.txt in Conan2.X:

[options]
adg_compatibility=50.1.1
variant=GEN3
[requires]
baseimage/icas1_50@test_channel/stable

Also the requires package version looks diferent.

In our project we used the conaninfo.txt really often, especially the properties conan.package.*

[memsharded]

The conaninfo.txt file in Conan 2 has been reduced, to contain exclusively the information that defines the package_id. In fact, the package_id is now just the hash of the file, this simplifies a lot the management and also the understanding of the different effects of the different factors (settings, options, dependencies) on the package-id.

The conaninfo.txt in Conan 1.X had a lot of information there that wasn't part of the package_id at all.

The [requires] part of the conaninfo.txt has also changed, because Conan 2 implements a much better and thorough model of the effects of the dependencies versions in the consumer packages. This model now takes into account things like the package types (being static, shared, interface, etc), and can save a lot of unnecessary re-building from source, while being very safe. You have more information about this model in https://docs.conan.io/2/reference/binary_model.html

[Jannis1994]

Thanks for the clarification.

Best regards,
Jannis

[Jannis1994]

closed

[memsharded]

Thanks to you for the feedback!

If you can, please follow #17203 too, it would be great to have your feedback when this is merged and release. Thanks again!

[Jannis1994]

Sure I will consider it, as soon as it is merged.

[Jannis1994]

Hello again, during migration to Conan2 we saw another problem. It is mainly about the former conan.requires attribute visible in Artifactory when selecting conaninfo.txt properties view. In the past some other scripts used it for further evaluation and it would be great if we could add this attribute atleast manually. Is it possible to extend the standard attributes (conan.package.channel, conan.package.license, conan.package.name etc,) with a custom attribute? I saw methods like package_info() but I dont get it visible in the properties overview and I dont want to add it as an option, as it is mainly a parameter like the version, we also have other custom properties in mind, that we would like to add.
So increasing the metadata would be great and be able to add custom attributes which are also visible like url, license, author, description etc.

Was thinking of something like the following:

def package_info(self):               
        self.conf_info.define("conan.package.test_attribute", "test_value123")

Could you maybe help us again?
If it is not possible, I think we have to use conan graph info and put the output to a json file. Do you know where the information is now stored within the conan package, if it is not anymore the conaninfo.txt? Or is it only reachable via a conan command and not directly in one metadata file?
Otherwise we may would use this approach without properties but files with the content we need: https://docs.conan.io/2/devops/metadata.html and self.package_metadata_folder in build method

Thank you and best regards,
Jannis