[question] Managing internal dependencies with versions handled by CI system

[fschoenm]

What is your question?

Hello, I wonder if you have a recommendation for handling the following scenario:

Imagine we have two repos libA and libB. libB depends on libA. Out CI system checks out both repos, usually on the master branch but it can be any tag or branch, configured in the CI system. Then we build both libs together manually.

I now want to create a conan package of libA and consume the package in libB. However, I'm not sure how to correctly use the version of libA. What's the best approach here?

• Should I just set a custom version like "1.0" or even "latest" and depend on that version in libB?
• Or is there a way to give a more reasonable version to the package? Ideally I'd like to use the branch/tag (e.g. libA/master) name but then I don't know how to refer to the correct version in libB.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @fschoenm

I now want to create a conan package of libA and consume the package in libB. However, I'm not sure how to correctly use the version of libA. What's the best approach here?

In principle, if the libB depends on libA the idea is that to build libB you already need to define the package libA and the version you want to use to build libB. Otherwise, there is indeed an indetermination problem, as you are trying to package something (libB) trying to make it depend on something else (libA), but in reality the package libB doesn't depend on the package libA because you didn't need nor use the package libA to build it.

This is the duality of mono-repo development and component/package-based development. If libB and libA are to be independently versioned and released packages, they need to be independently developed and versioned, and consumed accordingly by the consumers when the consumers need to build themselves.

Said that, there might be some possibilities to try to dynamically define some versions that make sense:

• In any case, versions and packages should be reproducible. It is not enough they are called liba/master and just be built from the "master" branch, because that is a moving target. So it is necessary to have some immutable origin, like a tag that is never moved, or a commit.
• You can get the commit of a folder with the Githelper, and use it in libA to define its version using set_version() method.
• You can get the commit of folder of libA in the export() method of libB, and store it in the conandata.yml. Then the requirements() method can use the self.conan_data to get that information and call self.requires("liba/{commit]")
• The same approach can be used for tags, typically a bit nicer for humans. You need to guarantee that the tags exist in the server for reproducibility.