Conan: Add a possiblity to build multiple library versions from a single recipe.

[bobeff]

Now the version of the library is a single string in the recipe. For example version = "0.11.4" in our RdKafka library recipe. It will be good in order for easier code reuse from single recipe to be able to build several different versions of the library. For example it can be added option version parameter to be a list of strings with all supported versions in addition to a single string as it is now and the desired version to be selected with additional option or setting or to be used the first or the last element in the list if such parameter is not specified by the user. This way especially for minor versions when there is no change in the build process and the library build options, the only additional code will be in the source method of the recipe when we have a multiple versions recipe. For example instead:

def source(self):
    tools.get("https://github.com/edenhill/librdkafka/archive/v0.11.4.tar.gz")

we can have:

...
version = ["0.11.5", "0.11.4"]
...
def source(self):
    tools.get("https://github.com/edenhill/librdkafka/archive/v%s.tar.gz" % self.options.version)

The current approach to split the code in multiple files is good if there is a bigger differences in the recipe, but it is simply too cumbersome if the differences are very little like the above example, when only the URL from which the library source code is being downloaded have to be changed.

[uilianries]

Hi @bobeff !

Conan provides python requires where is possible to create a single base Conanfile and reuse it:

from conans import python_requires

base = python_requires("RdKafka/0.11.4@user/channel")

class Pkg(base.RdKafkaConanFile):
    version = "0.11.5"

[bobeff]

Yes, thank you for the suggestion. I know about this feature, but I still think that in some cases it will be easier and better everything to be in a single file. I just investigating other users opinion about such a feature. It is not something very critical for me. As I know there was a previous interest in a feature like this and I think that maybe some other users also like me will find such an approach better for some of their use cases.

[lasote]

You can omit the version field in the recipe and export the full reference in the conan create and/or conan export commands.

conan create . RdKafka/0.11.4@user/channel
conan create . RdKafka/0.12.4@user/channel
conan create . RdKafka/0.13.4@user/channel

[bobeff]

@lasote This seems like to be able to solve the problem, although I did't try it yet. As I understood you suggest after omitting the version field to use ordinary option with the same name?

[lasote]

The name attribute could also be omitted if that is what you mean. If you don't declare "name" or "version" in the recipe you have to declare it when exporting.

[bobeff]

No, I mean that after omitting the version field, I have to have some way to determine the actual version in the recipe, for example in the source method, and that this can be done with adding an ordinary package option for the version. And this way no special support in Conan is required for this to work.

[lasote]

You can always access to self.version in the recipe.

[bobeff]

Yes, but it will be None if the field is not present I guess?

[lasote]

No, if you run "conan create lib/1.0@conan/stable" even if the field is not declared in the conanfile.py his value will be "1.0"

[bobeff]

But what about the time when the package is being developed and I execute source, build or package commands?

[bobeff]

Maybe adding an optional reference argument to this commands, as well to the other commands which accept path or reference, for the case when path is used, will solve this problem?

[lasote]

You are right. With the local methods, you don't have it available. Maybe following the comments here and the WIP here for user and channel could make sense to create default_version and default_name attributes/properties too.

[lasote]

I've commented on this issue #3734. I think we could close this and follow there the conversation.