conan-io
[question] Looking for most recent requirement's package with version ranges
What is your question?
Hi,
Let's consider a requirement using a version range, for example module/[~4].
When Conan installs the requirement for a given profile, for instance doing something like this:
$ conan install -u --requires=module/[~4] -pr=profile
it will download recipe and package for the requested profile of the most recent version 4.*.* of module found on a remote (if it isn't in cache yet).
This happens despite some less recent version 4.*.* already present in cache because of the -u argument.
If only the recipe of the most recent version is found, but no package, Conan returns with an error:
ERROR: Missing prebuilt package for 'module/4(...)'
which is something expected when no --build=missing or similar is given.
First question is of course if I understood correctly.
And now the actual (hopefully not too weird) question: Is there a way to tell Conan to look for the most recent module's version whose binary package for a certain profile is available too? In other words, if only the recipe of, say, version 4.8.0 is available on a remote, while an older (unknown by us) version, say 4.7.1, has the binaries too, can we tell Conan to get the requested binaries of 4.7.1 from the remote instead of trying 4.8.0 and rise an error?
TIA and kind regards.
Have you read the CONTRIBUTING guide?
- [ ] I've read the CONTRIBUTING guide
Hi @marausch
Thanks for your question.
This is not exactly what you are asking, but please have a look to https://docs.conan.io/2/knowledge/faq.html#getting-version-conflicts-even-when-using-version-ranges, because it is closely connected.
What you are asking for is almost impossible: Resolving to the latest version that contains a binary for a given configuration, is also an NP-hard problem, and with an even worse degree of complexity than the version-ranges resolution, because it operates on the "binary" computation that requires even more computation than resolving the ranges conflicts. This means the problem is intractable in practice
But what we have learned with our experience in the last years is that even if this sounds it would be a nice to have feature, it is not, it is actually a trap that can cause a lot of pain and problems. I'll give you an example:
- One dev does some important fix in the source code, solving an important vulnerability. This creates a new version or revision.
- The CI job triggers and start building binaries for the different configurations. For some reason of the servers for one configuration goes down, or simply the binary for that configuration is not fully uploaded due to some network issues.
- Now, the expectation would be that the consumers applications automatically resolve thanks to the version range to that latest change. Everything resolves nicely, but in one of the configurations, as the binary is not there, it will automatically fallback to the previous version that doesn't contain the important vulnerability fix.
So, in summary, it is much safer, intuitive and expected, that if there are some "source" changes (recipe, source code), and these changes kind of get approved, merged, or start to be used, is that irrespectively of the specific configuration, these source changes are the ones that must be used. And if for some reason there is no binary for those changes, it must either raise an error (to be safe, and it will evidence that there was a previous error in the process), or build a new binary from the source.
Please let me know if this clarifies the reasons.
Hi memsharded,
Your explanation couldn't be clearer... and it will help me a lot to convince some colleagues of mine. 😉
Great, happy to be able to clarify this.
I am going to re-open and move it to the Conan docs repo, to add there an entry in the FAQ, I think it is worth it.