[question] Force package versions for "paired" recipes

[Ahajha]

In "package pairs" such as vulkan-headers/vulkan-loader (and tcl/tk, there are other pairs as well), it is expected that the versions of the pairs should always be the same. Without force=True, we run into possible conflicts if there is another requirement for the first package. We usually resolve this by bumping the versions, but we cannot due that in this case since they are pinned together.

See this issue for an example of this happening: #23684

I propose that we add force=True to these "paired" dependencies, so that way the versions always stay together and don't cause conflicts.

[jcar87]

Is the issue not covered by something like this?

• For a "dual" require on the same recipe:

self.requires("protobuf/3.21.12")
self.tool_requires("protobuf/<host_version>")

• For paired recipes where the version must match 1:1

self.requires("libgettext/0.22.5")
self.tool_requires("gettext/<host_version:libgettext>")

I'm not sure it covers two (or more) regular requires for dependencies that should have the same version - if the recipes could express this, would that fix the issue?

I'm not sure that's the same experienced here: #23684 - this is just a regular conflict - even if vulkan-loader/1.3.268.0 was not in the graph.

[Ahajha]

The situations I'm referring to don't have anything to do with build requirements, these are all in the host context.

I suppose you're correct in that this is a regular conflict, but perhaps I could explain it a different way: If my recipe is requiring vulkan-loader, then I know I should always match the vulkan-headers version, to do anything else is asking for trouble. So to have this conflict come up where now another dependency is using vulkan-headers, in my opinion the only sensible thing to do is just always defer to the vulkan-loader version (and in turn, the vulkan-headers version). If I asked for a specific vulkan-loader version, and a conflict arises with vulkan-headers, I'm just going to add an override or force to resolve the conflict in the exact same way at the top level.

[ericLemanissier]

I guess the least we can do is to check in vulkan-loader's validate(self) that self.dependencies["vulkan-headers"].ref.version == self.version

EDIT: it's already checked : https://github.com/conan-io/conan-center-index/blob/master/recipes/vulkan-loader/all/conanfile.py#L75-L77 Maybe we should raise an exception instead (after doing an actual range comparison)

[Ahajha]

What is the range comparison that is TODOed there? It is a suggestion to turn it into a version range, or something else?

[ericLemanissier]

@SpaceIm could you please explain us the range your were talking about in 20fc0fe#diff-12dbf15b28e21af44691fedb226499a084ebc793ff1efbc12ce9b43f316401abR84 ?

[SpaceIm]

For example vulkan-loader 1.2.168.0 is compatible with 1.2.168.x versions of vulkan-headers.

[Ahajha]

I see, so for 1.2.168.0 we would need a version range like >=1.2.168 <1.2.169 or ~1.2.168. So generally

ver = Version(self.version)
required_vulkan_headers_version = f"{ver.major}.{ver.minor}.{ver.patch}"
self.requires(f"vulkan-headers/[~{required_vulkan_headers_version}])

Or maybe if it requires a greater-or-equal tweak version:

vk_headers_next_patch_version = f"{ver.major}.{ver.minor}.{ver.patch + 1}"
self.requires(f"vulkan-headers/[>={self.version} <{vk_headers_next_patch_version}])

Proposed with force=True.