test the concept of using python_require to modify package-id of consumers of build_requires

[memsharded]

Changelog: Feature: Proof that python_requires can be used (as a workaround) to affect the package_id of consumers of build_requires that otherwise will not be rebuilt based on changes.
Docs: conan-io/docs#1925

[solvingj]

This appears to me to be a brilliant solution. To re-iterate the use-case/problem this solves.

There are many issues where people wish build_requires would affect package_id. We plan to provide this option, but the refactor is so fundamental to the graph, that it really isn't feasible to implement into Conan in a non-breaking way, so we are reserving this for Conan version 2.

In the meantime, this solution provides the same net-effect.

To use this strategy, add the package you want to build_requires the same way you normally would (either via profile, or via the recipe). The only additional step needed is that you will add the same package reference to the recipe as a python_requires. You won't do anything with it as a python_requires, you won't call any functions from it or use a base class or anything like that. You just want it's contents to be included in the package_id of the consumer for the purposes of change detection etc.

Also of note, each time you update/bump the version of the build_require package, you'll need to update the version number in every recipe of every consumer as well.

One logistical implication is that it requires you to add the dependency explicitly in every recipe, whereas before you might have always fed build_requires to your builds through profiles. If you have hundreds of recipes, it's a big job to go add the python_requires to each one explicitly, and update the version whenever it changes. If you already used the build_requires via the consumer recipes, then it's less of a big deal IMO.

[memsharded]

Also of note, each time you update/bump the version of the build_require package, you'll need to update the version number in every recipe of every consumer as well.

If using version-ranges or revisions, using consistently the same in both places could avoid updating the recipes. Otherwise, yes, it is needed to bump the python_requires version in the recipes.

One logistical implication is that it requires you to add the dependency explicitly in every recipe, whereas before you might have always fed build_requires to your builds through profiles. If you have hundreds of recipes, it's a big job to go add the python_requires to each one explicitly, and update the version whenever it changes. If you already used the build_requires via the consumer recipes, then it's less of a big deal IMO.

Yes, this is a workaround, not a feature, to be able to modify the package_id until Conan 2.0 can model that. But as suggested above, if you user versioning consistently, you might not need bumping the python_requires versions in recipes all the time.

[memsharded]

@danimtb @solvingj I suggest moving this forward as this test, and a short note (as workaround) in the docs. Good for you? If yes, I will write the docs for it before the release.

[solvingj]

We should see if @theodelrieu has any additional thoughts or suggestions since he is one of the earliest known requesters of build_requires pacakge irelationship.

[theodelrieu]

This looks promising!

I've never used python_requires though, is there a way to do conditional python requires? Just like with build_requirements() and requirements()?

[memsharded]

I've never used python_requires though, is there a way to do conditional python requires? Just like with build_requirements() and requirements()?

No, python_requires are evaluated at recipe import time, well before that the recipe has any settings, options or anything else defined. Plus the recipe might actually extend a base class existing in the python_require, that will itself define the configuration, so that would be a chicken & egg problem. They are a "dynamic" import, in which we need to delay the import until the dependency package is retrieve to the Conan cache.

[danimtb]

please include the docs workaround as well and indicate is this would close any issue related. thanks!

[memsharded]

Docs added.

indicate is this would close any issue related. thanks!

Not really, those issues cannot be considered closed, this is a workaround, not a full solution.