-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conan 2 support #8383
Comments
The way the ORT analyzer works is that it needs to be able to decide "from the outside" of the project under analysis (like by files being present or not), which package manager implementation it should use. So if there is a reliable way to tell whether a project is a Conan 1 or Conan 2, then implementing Conan 2 as a separate plugin should work straightly. As I'm not a Conan expert, for me there are a bunch of more questions to clarify, like: Is Conan 2 backwards compatible to Conan 1? So could we use only a Conan 2 binary to power both Conan 1 and Conan 2 analyzers? Or only have a single analyzer plugin for both on the ORT side after all? Maybe @jsteinhofff can chime in here? |
I guess this is good read: |
With some support of the user, this should be possible by adding required_conan_version to a Some additional thoughts/questions
Same here
(Partially):
I have no idea how many Conan 1.x recipes are not using "latest 1.X integrations", and therefore might fail to build with Conan 2. The simple ones I am using work seamlessly with Conan 2. The ones contained as test case in ORT do not (
Nope. Not if we want to support every project out there/not breaking backward compatibility.
By now, contradictory to my initial gut feeling, I think we should try to. |
Well, ORT only analyzes one project of the same type (i.e. manager by the same package managers) at the same time. Other analyzers may run in parallel by default.
No, because we need to be able to support both Conan 1 and 2 at the same time, so also both binaries need to be available at the same time.
In short, IMO, no. Of course we could document this as a requirements to run ORT, but I'm already seeing the bug reports that ORT does not work for users who don't specify that.
TBH, I don't know, as I have no feeling about how widespread Conan 2 is compared to version 1. |
How would you do this? When installed via pip, the binaries for version 1.x and 2.x are both called
As I have not (yet) found a way to reliably detect whether a recipe works with Conan 1.x, 2.x or both versions, I think one way or another some support by the user will be needed. Question is whether it should be the users of Conan version 1.x or 2.x.
Does this really matter? Conan 2 is the future, and it will dominate sooner or later. The intention behind my question was to figure out if ORT values "status quo can run unchanged" over "we make it easy to run modern stuff". |
I don't know yet 😸 But generally, ORT allows you run any of its supported package managers in any combination. Maybe we should simply consider Conan 2 to be a special case of Conan 1, and allow to configure it similar to the Python version.
No.
Ok, again similar to Python support then, as we cannot always reliably detect the Python version that should be used, but the user simply has to know and configure it for ORT.
IMO it matters, because we should make ORT easy to use for the majority of users. If Conan 2 is there but not yet widely adopted, I don't see a point in making the default now, but maybe only later. |
Hi there, not sure I can contribute much since I don't have a good understanding (any more) how the conan package manager integration works . Having a quick look at the code I get the impression that it boils down to
About the acceptable of Conan 2 I can only share from our company that I think we are quite far away from general adoption. We use Conan to share packages across teams, departments and even business units, this makes such a breaking change extremely difficult to tackle. No single entity can upgrade in isolation, supporting both versions is also cumbersome, and orchestrating a synchronized change everywhere is basically impossible in such far spread scenario. But due to this effect one could argue that rarely both versions would be coexisting in a single project/product/whatever the granularity is on which ORT runs. So I would suspect that a configuration option of the version to use is acceptable, it would probably then make sense to verify that the Conan command line tool indeed matches to this configuration. For what the default shall be of such configuration... I would assume the default should not break existing ORT instances, so it should be conan1. |
It seems like ORT currently supports only Conan 1.x. For my needs, I need support for version 2.
Questions:
The text was updated successfully, but these errors were encountered: