[question] Conan 1 and Conan 2 package coexistence in Artifactory?

[harsszegi]

Hi,

we are running 7.84.20 of Artifactory, and testing Conan 1 and Conan 2 coexistence. I have a header-only package that I have uploaded first via Conan 2 and then Conan 2

The 621a86... was created with Conan 1 The 85da... was created with Conan 2

When I try to compile a package that uses this header-only package with Conan 2, I get the following error:

foo/3.0.5+feature_conan2+558-7ff7509@channel/dev: Downloaded recipe revision 621a867a8523e1d398df99322f4d1f77 Graph root conanfile.py (base64/2.rc.08+feature_conan2+17-5cc1855-dirty@channel/dev): D:\workspace\packages_merged\base64\conanfile.py Build requirements foo/3.0.5+feature_conan2+558-7ff7509@channel/dev#621a867a8523e1d398df99322f4d1f77 - Downloaded (artifactory) Python requires bar/4.0.1+feature_conan2+132-8244101@channel/dev#48fb12a10edb5262eae6b33e54ed6be8 - Downloaded (artifactory)

======== Computing necessary packages ======== Build requirements foo/3.0.5+feature_conan2+558-7ff7509@channel/dev#621a867a8523e1d398df99322f4d1f77:da39a3ee5e6b4b0d3255bfef95601890afd80709 - Missing ERROR: Missing binary: foo/3.0.5+feature_conan2+558-7ff7509@channel/dev:da39a3ee5e6b4b0d3255bfef95601890afd80709

foo/3.0.5+feature_conan2+558-7ff7509@channel/dev: WARN: Can't find a 'foo/3.0.5+feature_conan2+558-7ff7509@channel/dev' package binary 'da39a3ee5e6b4b0d3255bfef95601890afd80709' for the configuration:

And this is not surprising, as the Conan 2 recipe version is 85da...

Can anyone explain how should Conan 1 and Conan 2 package coexistence work with Artifactory? Thanks,

[AbrilRBS]

Hi @harsszegi While Conan 1 and 2 packages can coexist in the same Artifactory repository without problems, and they will share recipe revisions just fine, the package id calculation is totally different between version, which means that they won't find binaries built with one of the versions using the other version.

This is expected behaviour, as the two models differ substantially so it's not possible to share them across versions, so you'll need to have different pipelines for each version if you desire to keep compatibility with both versions, something like Conan Center Index does.

Hope this helps, let me know if you need any more insight, happy to help! :)

[harsszegi]

Hi @AbrilRBS,

sorry, I don't fully follow :( How can they coexist then? In my example the recipe revision is not shared, I get different one for Conan 1 and Conan 2 (see the picture). I have exported and uploaded from the same Git repo from the same Git revision a header-only package, the only thing that differed was the Conan version used. Using Conan 1 and Conan 2 produced different recipe versions - as you can see from the screenshot.

So currently I can't use Conan 1 and Conan 2 at the same time with the same Artifactory instance.

I have "revisions_enabled = True" and "default_package_id_mode = semver_direct_mode" for Conan 1 - if that matters. Please advise. Thanks,

[harsszegi]

Meh, we still had "scm" in the conanfile.py :( What is the current strategy to capture the scm information if the package doesn't have conandata.yml?

[jcar87]

Hi @harsszegi - thanks for your question.

Given a recipe with its version, in your case foo/3.0.5+feature_conan2+558-7ff7509 - the recipe revisions are shared between both Conan 1 and Conan 2. Conan 2 (or Conan 1 with revisions enabled) should pick up the most recent recipe revision - in Conan 2 you should be able to do:

conan list "foo/3.0.5+feature_conan2+558-7ff7509#*" -r <name_of_your_remote>

to confirm that Conan 2 is able to see both the revisions you have uploaded (one from Conan1, and another from Conan 2). I suspect that in your case, the "recipe revision" generated by Conan 1 is more recent than the one from Conan 2 (as seen by the server upon upload), so Conan 2 is just picking that one up.

It's a different case with package_ids - For the same recipe revision, Conan 2 will only see packages created with/for Conan 2, and Conan 1 will only see packages created with/for Conan 1.

The strategy for coexistence that we have applied in Conan Center is that recipes use a syntax that is compatible with both Conan 1.x (recent versions) and Conan 2 - so the recipe revisions are shared amongst the two major Conan versions, but the packages are different.

If this is not your case, and you cannot have a single recipe satisfy both Clients altogether, I would advise just segregating the recipes to different repositories in Artifactory as a possible solution.

[memsharded]

What is the current strategy to capture the scm information if the package doesn't have conandata.yml?

Not sure what you mean, the scm can generate the conandata.yml on the fly if necessary, that is, something like Git(self).coordinates_to_conandata() will create the conandata.yml to store the scm coordinates. (see https://docs.conan.io/2/examples/tools/scm/git/capture_scm/git_capture_scm.html)

To summarize above feedback:

• If possible, we would recommend using the same Artifactory repository for both Conan 1 and 2, but only if the same recipe revision is produced with both Conan 1 and 2. This is possible in the majority of cases, as the same conanfile.py recipe and conandata.yml can be used for both Conan 1 and 2, producing the same recipe revision. This approach would be recommended because having a single codebase with just 1 recipe helps in the transition, instead of having 2 different diverging codebases.
• If for any reason it is not possible to achieve the same recipe revision, for example, because using different source recipes for Conan 1 and 2 (discouraged), then it is necessary to use different Artifactory repositories, one for Conan 1 and a different one for Conan 2.

Please let us know if you have any further question.

[memsharded]

Hi @harsszegi

Any further question or follow up feedback here? Thanks!

[harsszegi]

Oops sorry my bad, perfect answer, thanks a lot closing it!