[bug] Urgent Issue: New recipe revisions using "conan.tools" rather than "conans.tools" breaks using Conan 1.x

[anderson-dev]

fmt package recently updated all their package versions with new recipe revisions using modern conan.tools.scm import rather than the old conans.tools.scm. It is my understanding that all tools should now be accessible using this new namespace. However, all of our product packages have stopped being able to be built due to our dependence on spdlog package which pulls in fmt package. Because we have no way to specify to use the last known working revisions, all of our work is at a standstill.

https://conan.io/center/fmt?version=8.0.1&tab=recipe
Rev d56acdf89ece13fd090984aa02ce976f breaks all of our builds
Rev 2faedbfbef76facba31c990715794271 worked fine

Is there any temporary workaround to use the previous revisions of fmt package that worked until this issue is resolved in Conan?

Environment Details (include every applicable attribute)

• Operating System+version: Windows 10
• Compiler+version: MSBUILD
• Conan version: 1.50.0
• Python version: 3.10.0

Steps to reproduce (Include if Applicable)

1. conan info fmt/8.0.1@ -r conancenter

Logs (Executed commands with output) (Include/Attach if Applicable)

ERROR: fmt/8.0.1: Cannot load recipe.
Error loading conanfile at 'C:\Users\aflorence\.conan\data\fmt\8.0.1\_\_\export\conanfile.py': Unable to load conanfile in C:\Users\aflorence\.conan\data\fmt\8.0.1\_\_\export\conanfile.py
  File "<frozen importlib._bootstrap>", line 684, in _load
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 
678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "C:\Users\aflorence\.conan\data\fmt\8.0.1\_\_\export\conanfile.py", line 5, in <module>
    from conan.tools.scm import Version
ModuleNotFoundError: No module named 'conan.tools.scm'

[anderson-dev]

looks like this may be related to issue #11676

[memsharded]

Hi @anderson-dev

yes, this is apparently a bug in the pyinstaller creation, not in Conan itself. It has already been fixed for next 1.51, you might try to use the pip install alternative in the meantime to try this new feature (I guess it never worked for you if using the pyinstaller)

[ghost]

This is an urgent issue for me as well. pip install didn't work. Please release 1.51 as soon as possible.

[memsharded]

But this is not broken, it simply never worked. conan.tools.scm is a new, experimental feature. Apparently, it never worked in the pyinstaller, so it is not possible that this is a breaking change in any way, am I missing something?

A different thing is that it doesn't work with the pip install, but we would need some more details. So far it seems that it is working fine, we have users using it without problems. Are you sure your are calling the pip installed Conan, and not the other one? Have you uninstalled it first?

[gegles]

Somehow I am now just starting to see the same issue on all my Windows build machines....Not sure what changed...

The version of fmt does not matter, fails with 8.0.1, 8.1.1 and 9.0.0

[memsharded]

Hi @gegles

Somehow I am now just starting to see the same issue on all my Windows build machines....Not sure what changed...

We would need a few more details please:

• Are you using latest Conan version?
• Are you using the Windows installer or pip install?

[ghost]

To follow up, I had issues with pip install because python was being compiled from sources without the sqlite3 libs. Once I fixed that pip install conan fixed the issue, as reported

[memsharded]

To follow up, I had issues with pip install because python was being compiled from sources without the sqlite3 libs. Once I fixed that pip install conan fixed the issue, as reported

Yes, that is true, the based Python used for Conan has to have sqlite3 support.

[gegles]

Hi @gegles

Somehow I am now just starting to see the same issue on all my Windows build machines....Not sure what changed...

We would need a few more details please:

• Are you using latest Conan version?
• Are you using the Windows installer or pip install?

I actually used choco install conan on Windows... Could this be the culprit? I'm gonna try pip install... and see.

[anderson-dev]

Same here installed via choco. Glad to have a potential emergency plan with pip install potentially but it’s still a giant pain because I’d have to instruct all our developers to do so and modify, rebuild, and republish both of our Windows Docker build images to change the install script which usually takes several hours

…

Sent from my iPad

On Jul 22, 2022, at 3:07 PM, Guillaume Egles ***@***.***> wrote:  Hi @gegles Somehow I am now just starting to see the same issue on all my Windows build machines....Not sure what changed... We would need a few more details please: Are you using latest Conan version? Are you using the Windows installer or pip install? I actually used choco install conan on Windows... Could this be the culprit? I'm gonna try pip install... and see. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[memsharded]

Same here installed via choco. Glad to have a potential emergency plan with pip install potentially but it’s still a giant pain because I’d have to instruct all our developers to do so and modify, rebuild, and republish both of our Windows Docker build images to change the install script which usually takes several hours

The choco package is not maintained by us, by the way. I think when we release the fix in the pyinstaller in 1.51., it will be used automatically, but cannot be sure.

Also, I am still missing information to know if this is a regression or not. So far, it doesn't seem so, but this is something that never worked in Conan installations created from pyinstaller. If someone has some evidence that this is a regression, we could try to backport it to regressed released versions.

[anderson-dev]

Anyway to give a warning to conan index publishers to avoid using this feature until 1.51 is out?

[memsharded]

Anyway to give a warning to conan index publishers to avoid using this feature until 1.51 is out?

Warnings is not really a thing for ConanCenter publishers, many things are automated, they will either block or warnings will not be read. And it is not possible to block because these already approved and merged features are correct, and have been released a couple of releases ago (1.48, it seems, https://docs.conan.io/en/latest/changelog.html). In any case, 1.51 will be released in a couple of days, so I am closing this as implemented in #11677

Recall that in general it is not recommended to depend on ConanCenter in production but better use your own copy of packages in your own repo, to isolate your production environment from possible issues in ConanCenter, from outages, to unwanted recipe updates. It might also be possible pinning exact recipe revisions in requires or using lockfiles, but that wouldn't protect production environment from infra, network or other issues.

[anderson-dev]

For those needing a workaround until Conan 1.51

Specifying the previous, known working revision discovered from conan center website in your requires alleviates the issue until Conan 1.51:

self.requires("spdlog/1.9.2@#743be2f16763efa5a573562315ef3611")
self.requires("fmt/8.0.1@#2faedbfbef76facba31c990715794271")

I tried using a proxy-mirror in Artifactory but unless you pin the specific revisions, the proxy just downloads the latest revision anyway (even after purposely deleting it from our proxy) due to our normal use of --update in all our conan install commands in CI

[anderson-dev]

I understand this feature never worked but fmt changed all of their packages to use this feature forcing us to downgrade from spdlog/1.9.2 to 1.4.8 or so as a temp workaround which resulted in many bugs that we had to fix on the fly. Our entire team was down a full day and a half because all of our products use spdlog for logging. We’re hobbling along now but if just one more dependency starts using the new feature before 1.51 we’re hosed. The package providers are doing the right thing by requiring the correct version of Conan that supports the feature but is breaking for a large portion of their consumers unknowingly

…

Sent from my iPad

On Jul 21, 2022, at 12:54 PM, James ***@***.***> wrote:  But this is not broken, it simply never worked. conan.tools.scm is a new, experimental feature. Apparently, it never worked in the pyinstaller, so it is not possible that this is a breaking change in any way, am I missing something? A different thing is that it doesn't work with the pip install, but we would need some more details. So far it seems that it is working fine, we have users using it without problems. Are you sure your are calling the pip installed Conan, and not the other one? Have you uninstalled it first? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[memsharded]

Hi @anderson-dev

We tried to summarize some of these ideas in https://blog.conan.io/2022/09/20/consuming-recipes-during-migration-conancenter.html.

Basically, the most robust way to isolate from upstream ConanCenter changes is to store a copy of the packages you need in production. Not proxying them via a remote repo, because that updates automatically (I am not sure if there is some configuration there that would allow not updating), but just a normal copy to a local repo. In that way there is absolutely nothing that can break you. I'd recommend doing it right now, it should be relatively easy, copying all the remote contents to a local repo, then using that as remote, because the community is working a lot to upgrade ConanCenter recipes to 2.0, and some other changes requiring latest 1.X will eventually happen.