Open tobifalk opened 8 months ago
This prevents users from using a custom user/channel and may be considered as a bug.
Or a limitation of Conan. We need the private
attribute here to indicate that this is not a transitive dependency. Unfortunately, Conan doesn't really seem to provide good methods to work with custom user/channel values.
While it's easy to create new packages with custom user and channel, I can't find a simple method to override this for its dependencies.
What I'd like is the ability to do this with Conan:
packageZ@userX/channelY
is taken instead.*@userX/channelY
.However, to the best of my knowledge, this is not possible.
Possible solution A: All the cloe packages to assume that its dependencies should have the same user/channel as it itself. When requiring any package that would have cloe/develop
, replace this with the user and channel of the package itself.
This has some downsides. The assumption above may not always hold. I regularly build the cloe-engine
package with different user/channel combinations during development, but don't want dependencies to change.
Possible solution B: Similar to with the VERSION
file, allow overriding of the user/channel
as well via a file, such as USERCHANNEL
. This could allow overriding of the user/channel for a package on the command line.
This complicates the tooling however and needs to be weighed against the benefit we gain from it. I have so many bad experiences with providing too many options in the build tooling. It gets error-prone and a chore to maintain.
Possible solution C: In a corporate context, work with your own "version" of the Conan-Center-Index. You have full control over all the recipes and can support multiple versions of the software simultaneously better than we can with immutable releases. You can code the ability across the board to use a user/channel, which you can set centrally in the tooling.
Without knowing what you exactly want to achieve with the custom user/channel, I can't say much on the pros or cons of this solution. However, I have looked into this solution for some other problems with distribution, and it looks more and more appealing to me.
Although the build process supports setting PACKAGE_CHANNEL via command line, which indeed creates the packages with the desired user/channel, problems arise when trying to deploy Cloe packages from a custom channel.
This is exactly what I meant by adding variability increases complexity and prevalence of bugs. This use-case you describe simply hasn't been exercised in our own CI systems. I simply figured, if I'm setting the user/channel with the Conan command, I might as well make it configurable. I guess it only goes so far.
Although the build process supports setting
PACKAGE_CHANNEL
via command line, which indeed creates the packages with the desired user/channel, problems arise when trying to deploy Cloe packages from a custom channel.i) In the Conan recipes, the requirements' user/channel is hard-coded, s. e.g. cloe-engine. For most requirements, this can be overridden by adding each and every Cloe dependency with an
override
to the deployment recipe's requirement method. This may or may not be considered an inconvenience, but not a bug. One may think about providing a mechanism to consistently inject a custom user/channel into the Cloe package bundle, though.ii) The main issue stems from requirements defined with the
private
attribute, as these cannot be overridden (e.gcloe-oak
in the cloe-engine recipe). This prevents users from using a custom user/channel and may be considered as a bug.