[question] conan-2.0.4 and conan inspect with set_version

[maitrey]

What is your question?

Dear Conan Folks,

For all my recipes, I use the below code to determine the version of packages:

def set_version(self):
        git = Git(self)
        try:
            gtag = git.run("describe --exact-match --tags")
        except ConanException:
            gtag = None
            pass
        if (gtag is None):
            branch_name = git.run("symbolic-ref --short -q HEAD")
            commit_id = git.run("rev-parse --short HEAD")
            if (os.environ.get('JENKINS_HOME') is None):
                self.version = "0.0.0-dev.0"
            else:
                if (os.environ.get('BUILD_ID') is not None):
                    build_id = os.environ.get('BUILD_ID')
                    self.version = "%s.%s" %("0.0.0-dev", build_id)
        else:
            try:
                tag_version = semantic_version.Version(gtag)
            except ValueError:
                print("Git tag is not as per semantic versioning")
            else:
                self.version = "%s" %(gtag)

I use conan inspect command and the below command returns null as the version:

conan inspect . --format=json | jq .version -rj -j
null

I use conan version 2.0.4. What am I missing? Could someone please help me?
Thanks!

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[AbrilRBS]

Hi @maitrey thanks for your question.

What's the output of conan inspect . by itself? Looking at the code maybe the tags are not valid semver?

The logic is a bit complicated so if you could try to create a reduced test case it would help a lot, a simpler version locally does work as expected :)

[maitrey]

Hi @RubenRBS ,

Here is the output of conan inspect:

$ conan inspect .
description: ASW
exports_sources: ('include/*', 'CMakeLists.txt')
generators: []
name: asw
no_copy_source: False
package_type: header-library
python_requires: autosarcommonlib/1.0.0@autosar/bringupconan2
python_requires_extend: autosarcommonlib.AutosarBase
revision_mode: hash
settings: ('os', 'compiler', 'arch', 'build_type')
topics: ASW

The set_version I have modified to have different naming convention for branch builds and tag builds. conan inspect says that it supports set_version: https://docs.conan.io/2/reference/commands/inspect.html?highlight=set_version

[maitrey]

Also, all of it was allowed in 1.x: https://docs.conan.io/1/howtos/capture_version.html and I used conan inspect which was working well to provide name and versions of the recipe. I wonder why conan inspect was changed in 2.x .

[AbrilRBS]

Oh sorry for the confusion, I would have sworn that 2.0.4 already had support for it and that's why it confused me as to why it was not working.
#13716 was merged for 2.0.5, which explicitly enables support for set_version/set_name. Can you try with that version and let me know if it works now? Thanks!

[maitrey]

Oh No :( . With 2.0.5 I actually read some issues last evening and saw there was a fix for conan inspect but did not find a mention about it in the Changelog. Has 2.0.5 got changes with respect to global.conf?
I tried upgrading to conan-2.0.5 last evening just to try but even the conan create command was failing for me with:
Conan cmd is:

conan create . --user autosar --channel bringupconan2
ERROR: [conf] 'path' does not exist in configuration list.  Run 'conan config list' to see all the available confs.

And the only place where I use path is in the global.conf:

path+=(path)C:/Program Files/CMake/bin

[AbrilRBS]

Oops, you found an issue with our release process. For some reason the changelog in the docs for 2.0.5 was not complete! (Already fixed by @czoido conan-io/docs#3235, thanks for noticing 😃)

If you look at the full changelog (Also available in https://github.com/conan-io/conan/releases/tag/2.0.5) the inspect changes do show up there.

As for your global.conf problem, no changes between both versions as far as I know, but after #13832 Conan now fails when an unknown conf is defined, to catch cases just like this!

That line in your conf is not having any effect in Conan 2. Env variables should be modified in the [buildenv] and [runenv] sections of your profiles (See here for the docs)

Also, if what you're trying to achieve is to have your own CMake used instead of having Conan download/build it when a recipe has a self.tool_requires("cmake/..."), I recommend using the new [system_tools] feature (Docs here). When Conan finds such a requirement, it will first look into your defined system tools and try to resolve from there, and only look into your cache & remotes if it does not find a match in the [system_tools] section.

Then, to have Conan find the proper CMake, you have then two options:

• Add that same line path+=(path)C:/Program Files/CMake/bin to the [buildenv] section of your profile as mentioned above
• Or after 2.0.6 is released (Scheduled for release today!), you'll have Add tool configuration to specify CMake executable path (#12701) #13940 available, which adds tools.cmake:cmake_program as a conf, in which you can define the path to your CMake explicitly in your global.conf or via CLI

I hope this makes a bit more sense now why you were seeing that error and the way forward, but please do not hesitate in asking any other question should you have more :)

[maitrey]

conan inspect now works with 2.0.5 and the global.conf works only with:

user.path+= (user.path)C:/Program Files/CMake/bin

Thanks for fixing the changelog.

[memsharded]

Just beware that:

user.path+= (user.path)C:/Program Files/CMake/bin

Has no effect at all in Conan. Only recipes explicitly loading self.conf.get("user.path") will access that binary.
And that seems wrong, it shouldn't be necessary to do that to have CMake in the path. Please check @RubenRBS recommendations above how to handle this with [buildenv] in profiles, or with the new conf once it is released.

[maitrey]

Hi @memsharded ! Thanks for noticing my comment and also helping me fix my issues. I will add the path variables to the buildenv section of the profiles. Many thanks for your support!

[memsharded]

Happy to help! 🙂