Add support for Conan

[JamieMagee]

What would you like Renovate to be able to do?
Add support for Conan, a C/C++ package manager

Describe the solution you'd like
Native support for Conan (using Bintray) as a datasource, and Conan as a manager.

Describe alternatives you've considered
Regex manager, but we don't provide support for Bintray as a datasource, so it won't work.

Additional context

• conanfile.txt
• Conan remotes
• Bintray REST API

TODO

• Add a Conan datasource #11474

[UnderSampled]

Also important is support for conanfile.py files: https://docs.conan.io/en/latest/reference/conanfile/attributes.html#requires

[okainov]

Any updates on this one? This would be very useful

[JamieMagee]

@okainov Not really. The community seems to be focusing on #7135 first.

[mhetzel]

@rarkins for the digest vs updating the release config api issue. I'm hoping to have a solution where if a user specifies user and channel only versions matching will get applied. I'm sure there's a better way to do it than update the api but trying to shoehorn digests to work for this also felt icky. Any suggestions would be great. My next thought is to include user/channel in the version itself and/or just revisit using digest.

[rarkins]

Can you give us some background on user/channel and how it applies to lookups?

I am trying to understand:

• Examples of how/when it's used
• Is it something which can only be filtered on the "server" side? (in which case we may need to add new fields to getPkgReleases, but probably more generic than "user and channel")
• Or is it something where we could leave the filter off, get back all results, and perform the filtering ourselves on the "client" side?

[mhetzel]

The user/channel bit is not my favorite feature. Conan itself is trying to move away from its use in their main registry. But its real use comes in in a large company with multiple teams and a self hosted registry. Consider teamA and teamB both working independent of each other developing nonoverlapping packages. They can both upload a "utilities" package and avoid collisions by maintaining separate user/channel specifications. Its kind of like namespacing. Both utilities packages are completely different and each team needs a way to only consume their own. As far as which side the filtering goes on. To me it would make sense to filter on the look up/server side. But either side would work.

[rarkins]

So user/channel is optional, and it's essentially a namespace? If so then could it be part of lookupName? If so, would that work.. would we need to invent our own syntax or is there a way of putting it in a single string already?

[mhetzel]

Correct super optional and basically a namespace. I can mess around with appending it to the lookupName, that shouldn't be hard at all. It will look weird since the format for conan is: name/version@user/channel. I could also let it be part of the version string and let it get filtered out via isCompatible

[rarkins]

Does lookupName include the /version part though?

[mhetzel]

It could! I'm just now seeing that there is both a depName and lookupName. Let me see what kind of behaviour I get with that.

[rarkins]

When you define both, depName is kind of the "human readable name" while lookupName is the actual string passed to the datasource for lookup

[mhetzel]

Defining both worked perfectly

[aishasteege]

This would be super helpful!

[viceice]

This would be super helpful!

Please don't fill the issue with those comments, use the 👍 emoji to vote this up.

The pr #12009 is nearly ready, so Please be patient.

[renovate-release]

🎉 This issue has been resolved in version 31.78.0 🎉

The release is available on:

• GitHub release
• 31.78.0

Your semantic-release bot 📦🚀