[question] Confusion around python_requires using minor_mode

[realbogart]

We are getting errors due to missing binaries for some dependencies and we don't understand why. Here is the result of running conan graph explain:

======== Closest binaries ========
my_dependency/5.2.4@external/testing
  my_dependency/5.2.4@external/testing#503edcf3f4fa9e8485a48242b8ef59af0189dfae%1718701720.397 (2024-06-18 09:08:40 UTC)
    my_dependency/5.2.4@external/testing#503edcf3f4fa9e8485a48242b8ef59af0189dfae:dfa7417ff0c5411e968cd171cff1894a0c5049e5
      remote: artifactory-local
      settings: Windows, x86_64, Debug, msvc, 17, static, Debug, v142, 192, Windows
      options: BuildConfiguration=Debug, ITERATOR_DEBUG_LEVEL=2, UniversalBuild=False, fPIC=True
      python_requires: my_python_requires/3.3.1@internal/stable#3361cb4779f74091834b3dec2b3f52002361059e
      diff
        python_requires
          expected: my_python_requires/3.3.Z@internal/stable
          existing: my_python_requires/3.3.1@internal/stable#3361cb4779f74091834b3dec2b3f52002361059e
        explanation: This binary has same settings, options and dependencies, but different python_requires

We are using the following default_python_mode setting in global.conf: core.package_id:default_python_mode=minor_mode

Shouldn't it then find the binary since both the major and the minor version matches?

Thank you!

[memsharded]

Hi @realbogart

Thanks for your question.

If the existing binary has:

existing: my_python_requires/3.3.1@internal/stable#3361cb4779f74091834b3dec2b3f52002361059e

It means that the binary was created using revision_mode instead, not minor_mode. Maybe the mode was temporarily changed?

It doesn't really matter that it matches down to the channel, the correspondence must be identical, as the package_id is the hash of it, it is not symbolical, it takes all the information in conaninfo.txt and hashes it. It is not doing any compatibility or analysis, either the resulting package_id is the same or not.

[realbogart]

Hi @memsharded,

I understand. Thank you for your answer.

Is it possible to manipulate conaninfo.txt after a package has been created? We ended up in a situation where we had to rebuild all packages just to update conaninfo.txt with the new minor_mode string.

[memsharded]

Is it possible to manipulate conaninfo.txt after a package has been created?

I am afraid it is not possible. Packages are immutable. The conaninfo.txt contents is also hashed in the conanmanifest.txt, and changing it would break the integrity of the package. Also, changing it a posteriori wouldn't change the package_id that was computed from it, as that was already stored in metadata, it is not computed all the time from conaninfo.txt. Maybe with a high expertise in server-side file and folders manipulation it might be possible to do a big hack, but sounds complicated and risky.

[realbogart]

That all makes sense. Even though I understand the technical reasons for why we had to rebuild the packages, I feel that it shouldn't be necessary. But that would then require a fancier comparison of the parts of conaninfo.txt, instead of just a hash.

Thank you for your help!

[memsharded]

That all makes sense. Even though I understand the technical reasons for why we had to rebuild the packages, I feel that it shouldn't be necessary.

I understand that. In general, the way package_id is managed tends to be "safer", in the sense that it is better to have to rebuild something because a package_id changed for some reason, than skipping a necessary build from source that will inevitably happen if the computation logic of the package_id from conaninfo.txt gets more complicated (as a reminder, we had a bit more complex computation in Conan 1, and it was not just hashing the conaninfo.txt, and it had some issues and challenges for very little value). Having a 1:1 correspondence between the package_id <-> conaninfo.txt and a very easy way to compute them, just hashing the file is overall and advantage, but yes, as always in computers, it is a trade-off.

I think the behavior is clarified, I am closing the ticket as resolved, but don't hesitate to re-open or create new tickets if you have any other question. Thanks for the feedback!

[realbogart]

Thanks again!