[bug] package_id depends on values from global.conf

[lo1ol]

Describe the bug

Conan version: 2.12

Hi!

I found out some conan behaviour, which may lead to some problems: conan may take package_id mode from global.conf to calculate package_id. Changing of change default_embed_mode/default_non_embed_mode/... values in global.conf may lead to fails in graph calculation.

I think it should be fixed, because I thought that calculated package_id shouldn't depends on configuration (or global.conf at least).

I know that I could set this modes in conanfile and it's what I'm gonna do in my Conanfile Extension. If you have an ability to set this attributes in conanfile, maybe usage of default_embed_mode/default_non_embed_mode/... should be marked as deprecated at least?

Ideally suggested package_id modes should be stored with conanfile during exporting

What do you think about that?

How to reproduce it

Example:

$ cat conanfileA.py
from conan import ConanFile

class AConanfile(ConanFile):
    settings = "os", "arch", "build_type"

    python_requires = "rutokenconanfile/0.35@rutoken/stable"
    python_requires_extend = "rutokenconanfile.RutokenConanFile"

    package_type="shared-library"

#    package_id_non_embed_mode = "full_mode"

    name="apkg"
    version="1.0.0"
$ cat conanfileB.py
from conan import ConanFile

class BConanfile(ConanFile):
    settings = "os", "arch", "build_type"

    python_requires = "rutokenconanfile/0.35@rutoken/stable"
    python_requires_extend = "rutokenconanfile.RutokenConanFile"

    package_type="shared-library"
    name="bpkg"
    version="1.0.0"

    def build_requirements(self):
        self.requires("apkg/1.0.0")

$ cat conanfileC.py
from conan import ConanFile

class CConanfile(ConanFile):
    settings = "os", "arch", "build_type"

    python_requires = "rutokenconanfile/0.35@rutoken/stable"
    python_requires_extend = "rutokenconanfile.RutokenConanFile"

    package_type="shared-library"
    name="cpkg"
    version="1.0.0"

    def build_requirements(self):
        self.requires("bpkg/1.0.0")

$ echo "core.package_id:default_non_embed_mode=minor_mode" >> ~/.conan2/global.conf
$ conan export-pkg conanfileA.py && conan export-pkg conanfileB.py
$ conan graph info conanfileC.py
    ...
   Success
$ echo "core.package_id:default_non_embed_mode=full_mode"  >> ~/.conan2/global.conf
$ conan graph info conanfileC.py
    ...
   WARN: There are some error(s) in the graph:
    - bpkg/1.0.0:98c138c2b63357ec3c62783ac89662755191b201: Missing binary

It happens because descrption of apkg in bpkg conaninfo differ from description that was created during calculation of cpkg's graph. And because of that package_ids of bpkg differ

[memsharded]

Hi @lo1ol

Thanks your feedback.

I found out some conan behaviour, which may lead to some problems: conan may take package_id mode from global.conf to calculate package_id. Changing of change default_embed_mode/default_non_embed_mode/... values in global.conf may lead to fails in graph calculation.

I am afraid this is exactly how it is designed and expected to work. This global conf affects "globally" to how package_ids are computed. If you change it, the computed package_ids change, and it is necessary to build the binaries.

The recommended approach is to use these configs as a general (global) versioning and binary compatibility policy, but this is not something intended to be changed from time to time.

I think it should be fixed, because I thought that calculated package_id shouldn't depends on configuration (or global.conf at least).

This cannot be changed, this is already used by tons of users. If you don't want that behavior, it is perfectly fine not to use it. But it is working exactly as expected (and as requested by many users, this is why this configuration is there and works the way it works).

[lo1ol]

Got you) May be this should be written somewhere in documentation?

We also don't want to has different global.conf versions:) But It was surprise for me, that changing of it may broke searching of packages

[memsharded]

Got you) May be this should be written somewhere in documentation?

Sure, moving the ticket to the docs repo

We also don't want to has different global.conf versions:) But It was surprise for me, that changing of it may broke searching of packages

Yes, the global.conf is not expected to change that much, the vast majority of configuration things should go to profiles.