docs
docs copied to clipboard
conan-io
version range not search remote any more since v1.30.0
When I installed conan v1.30.2, I found that "conan install mypkg/[^1.0.0]@aa/stable --update" only search from local cache, it will not search remotes. So that it reported the error like this: ERROR: Version range '1.0.0' from requirement 'mypkg/[1.0.0]@aa/stable' required by 'virtual' could not be resolved in local cache.
When I downgraded to 1.29.2. The issue was gone, seemed that it's a regression issue introduce since v1.30.0.
Hi @frank-xlj,
I am taking a look trying to reproduce your steps and I don't get a different behavior. For example, I have the ztsd/1.3.5@ reference installed in the cache. Here you have the commands:
$ conan search *
Existing package recipes:
...
zstd/1.3.5
$ conan install zstd/[^1.0.0]@ --update
ERROR: Version range '1.0.0' from requirement 'zstd/[1.0.0]' required by 'virtual' could not be resolved in local cache
$ pip install conan==1.29.2
...
$ conan --version
Conan version 1.29.2
$ conan install zstd/[^1.0.0]@ --update
ERROR: Version range '1.0.0' from requirement 'zstd/[1.0.0]' required by 'virtual' could not be resolved in local cache
Could you provide me with a small example to try to reproduce it from my side? Thank you
Hi @danimtb, Thanks for the feedback. Your experiment seemed to be another conan problem. To reproduce the issue I mentioned. You can just 'conan remove zstd' in your local cache, and then try "conan install zstd/[^1.3.5]@ --update" and "conan install zstd/1.3.5@ --update" with latest conan. And then try with 1.29.2.
Thanks for the feedback. Still I am seeing the same behavior from my side when using the steps you provided. Also tried with a reference with user and channel and it is working fine.
Could it be an issue with the server? Could you tell me what server are you using for the remote? Thank you
Hi @danimtb, You are raising a good point, and I am using an internal artifactory server which couldn't be accessed from internet. I tried your case (zstd package) which is using a public server, it works fine with latest conan version. So, I assume it should be our internal server problem. One thing I don't quite understand is that why server can affect the conan search behavior when running conan install. Should we update artifactory server to fix the issue?
Hi @frank-xlj
The key here is the version-ranges installation. Doing something like
conan install zstd/[^1.0.0]@ --update
Internally does a search in the server for the zstd/* package versions, and resolves the range in the client side. From my understanding this doesn't have changed in the server in a while, but if you are using an old Artifactory version, then that might be a possibility.
Thanks @memsharded for the explanation. Within our artifactory server which is v6.20.0 (released on May 25,2020 based on https://www.jfrog.com/confluence/display/RTF6X/Release+Notes#ReleaseNotes-Artifactory6.20 ), conan install with version range doesn't seemed to search remotes at all. When we run conan install, normally it will search local first, and then remotes one by one. But when we use 1.30.2, it just reported "ERROR: Version range '1.0.0' from requirement 'mypkg/[1.0.0]@aa/stable' required by 'virtual' could not be resolved in local cache.", didn't even search any remote like below: abc/1.0: Not found in local cache, looking in remotes... abc/1.0: Trying with 'conan-center'... abc/1.0: Trying with 'conan-local'... abc/1.0: Trying with 'conan-local-pwic'... abc/1.0: Trying with 'conan-local-k3p'... abc/1.0: Trying with 'conan-local-kal'...
But when we use 1.30.2, it just reported "ERROR: Version range '1.0.0' from requirement 'mypkg/[1.0.0]@aa/stable' required by 'virtual' could not be resolved in local cache.", didn't even search any remote like below:
If mypkg already exists in the local cache, then it will be resolved there. Once the package is installed in the client cache, you would need to do a --update to search in the servers first. But I don't think this has changed recently. Make sure to conan remove mypkg* -f when switching between versions.
That's quite weird. I do "conan remove .." and "conan search" before I run "conan install". My local cache is empty. I will discuss with other guys in my company to figure out the reason as well. Thanks for the help.
Hi @frank-xlj, did you manage to reproduce the issue? Otherwise please consider closing the issue, thank you!
This issue persists in conan 1.36; using a gitlab server, but as the original reporter says, the remote server search is not initiated, so I doubt this has anything to do with the server.
I should have said, using full reference with user/channel -- based on this test, https://github.com/conan-io/conan/blob/23ce09ad30e18872fb4caa39fd011cc1d5437cd4/conans/test/integration/graph/version_ranges/version_range_no_userchannel_test.py#L40, this is deliberate behaviour; I don't think this is documented anywhere, nor do I understand the rationale for this behaviour.
@tthef sorry, I didn't get it, the test is relatively straightforward, version-ranges shouldn't resolve to a package with different or no user channel, if you depend on requires = "pkg/[>1.0]@myteam/stable", you should only get resolution to something like pkg/*@myteam/stable, but never to other package from another team or even from conancenter (without user/channel).
@memsharded my apologies, I misread that snippet. I have used CONAN_TRACE_FILE now, and this is an issue on the gitlab remote, it fails to locate packages for the * version wildcard; the 'could not be resolved in local cache' comes from the remote. However, the conan error output here is not helpful, because this error gets printed without any indication that a query was made to the remote, so it looks like the remote is never contacted, even more as normally when something is not in the local cache you see 'Not found in local cache, looking in remotes...' etc.
gitlab has a ticket for this, https://gitlab.com/gitlab-org/gitlab/-/issues/329307, anyone hit by this issue might want to upvote that.