[bug] Requires ranges with version X.Y.Z.A sometimes can't be found in remote
See original GitHub issueEnvironment Details (include every applicable attribute)
- Operating System+version: Windows Server 2019
- Compiler+version: N/A
- Conan version: 1.41.0
- Python version: 3.8.2
Steps to reproduce
Some packages in our remote have versions of the form X.Y.Z.A
(usually for third-party packages to which we’ve done small changes to so we know what was the base version and the A
is versions of our changes).
However, sometimes it seems like Conan can’t find the package when using ranges of the form [>=X.Y.Z]
during the conan lock create
command.
Logs (Executed commands with output)
conanfile.py
in the test_conan
directory:
from conans import ConanFile
class TestConan(ConanFile):
name = "test-conan"
def requirements(self):
self.requires('aws-sdk-cpp/[>=1.6.53]@PORT/stable')
self.requires('avro-cpp/[>=1.10.2]@PORT/stable')
Conan searches on the remote:
E:\alefebvr\test_conan>conan search aws-sdk-cpp -r bb-conan-buildall-stable
Existing package recipes:
aws-sdk-cpp/1.6.53.7@PORT/stable
E:\alefebvr\test_conan>conan search avro-cpp -r bb-conan-buildall-stable
Existing package recipes:
avro-cpp/1.9.1.9@PORT/stable
avro-cpp/1.9.1.10@PORT/stable
avro-cpp/1.10.2.0@PORT/stable
When running conan lock create
command:
E:\alefebvr\test_conan>conan lock create ./conanfile.py --version 12345 --user PORT --channel stable --build=missing --lockfile-out=base_recipe_information_only.lock --base
ERROR: Version range '>=1.6.53' from requirement 'aws-sdk-cpp/[>=1.6.53]@PORT/stable' required by 'conanfile.py (test-conan/12345@PORT/stable)' could not be resolved in remote 'bb-conan-buildall-stable'
After commenting the line with self.requires('aws-sdk-cpp/[>=1.6.53]@PORT/stable')
in the conanfile.py
, rerunning the above command:
E:\alefebvr\test_conan>conan lock create ./conanfile.py --version 12345 --user PORT --channel stable --build=missing --lockfile-out=base_recipe_information_only.lock --base
[...]
Version ranges solved
Version range '>=1.10.2' required by 'conanfile.py (test-conan/12345@PORT/stable)' resolved to 'avro-cpp/1.10.2.0@PORT/stable' in local cache
[...]
Requirements
avro-cpp/1.10.2.0@PORT/stable from 'bb-conan-buildall-stable' - Cache
[...]
Packages
avro-cpp/1.10.2.0@PORT/stable:460c0b2d584d7832de0ef56497dc51330405ecca - Cache
[...]
Generated lockfile: E:\alefebvr\test_conan\base_recipe_information_only.lock
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
[bug] Range resolver stops after first remote #6743 - GitHub
Operating System+version: Ubuntu 18.04; Conan version: 1.24.0-dev; Python version: 3.6.9. I have a problem when using conan export-pkg with ...
Read more >git: fatal: Could not read from remote repository - Stack Overflow
This error means that you have not specified your remote URL location upon which your code will push. You can set remote URL...
Read more >Bug listing with status RESOLVED with resolution FIXED as at ...
Bug :2 - "How do I attach an ebuild. ... Bug:1305 - "pan won't build with without nls being present" status:RESOLVED resolution:FIXED severity:normal ......
Read more >Email non-delivery reports and SMTP errors in Exchange Online
When there's a problem delivering an email message that you sent, Microsoft 365 or Office 365 will generate an error code and often...
Read more >Apache log4j Vulnerability CVE-2021-44228 - Unit 42
Background and a root cause analysis of CVE-2021-44228, a remote code execution vulnerability in Apache log4j, with recommended mitigations.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yes, the 4th digit is basically ignored. There could be some randomness in the data structures ordering associated to order of creation, upload, or just luck that makes it work some times.
We have taken ownership of version-ranges and implemented our own solution, covering more than 3 canonical major.minor.patch. This is solved and released in 2.0-alpha, please try it when possible and report if necessary.