Conan Package Support

[uilianries]

Hello,

Do you know about Conan?

Conan is modern dependency and package manager for C/C++. And will be great if your library will be available via package manager for other developers.

Now we have famous C++ projects, including Google Flatbuffers. We could support you writing a recipe and publishing your packages on Bintray.

If you have any questions, just ask :-)

[ahedberg]

If I understand correctly, Conan distributes precompiled binary packages. Abseil does not promise ABI compatibility and recommends that its users compile from source at head. https://abseil.io/about/releases has more details.

[uilianries]

Conan distributes both source and precompiled binary packages, but is not mandatory. However mostly of author distribute some per-defined packages, including different compiler versions and platforms.

[zhangxy988]

Abseil has LTS branch which might be suitable for distribution in Conan since it's meant for projects who want to cut stable releases. We have one LTS branch so far https://github.com/abseil/abseil-cpp/tree/lts_2018_06_20.
Since I know no one on Abseil know how to write Conan recipe, it'd be great if you could help us on it.

[uilianries]

Sure! We could open a PR with the Conan recipe.

Regards!

[mbxx]

Conan support sounds like a nice thing to have, but I'm vaguely worried about the additional maintenance that comes from adding support for more build systems. (Not necessarily from adding support for Conan specifically, but I don't think this will be the last system that we're asked to support.) Is there a link I can read to get a sense of what supporting Conan would entail?

[uilianries]

I could support you when necessary, no problem.

As we are trying to keep both Conan recipe and your project on same repository, our strategy is here

And there are real life examples:

https://github.com/taocpp/PEGTL/blob/master/conanfile.py
https://github.com/google/flatbuffers/blob/master/conanfile.py

[solvingj]

Thanks very much to both of you for being open to the discussion.

Our team has been maintaining the Abseil Conan package since Abseil was released last year. It's been popular, and becoming moreso lately.

https://bintray.com/bincrafters/public-conan/abseil%3Abincrafters

As for the prospect of getting involved in packaging, your concerns are common and justified. There are quite a few distribution channels available to library maintainers nowadays, and it can be overwhelming and unclear where it makes sense to devote attention. I believe you're already supporting two build systems which I'm sure would be very challenging and time-consuming. For library maintainers unfamiliar with Conan, it is indeed a pretty substantial investment to try to create and support a proper Conan package from scratch.

Reducing that barrier for maintainers like you is one of the fundamental goals of our team. We've gone ahead and done all the heavy lifting, by creating the recipe, setting up CI to build across Windows, Linux, and macOS, and the package has been getting tested out by several users for a while now. Thus our immediate goal is to simply introduce you to the project, show you what we've done, and hopefully get your feedback. For example, recently we've had some uncertainty and github issues surrounding link ordering. We think they're ironed out, but confirmation from your team would be great.

In case you are willing to have a look, here is a link to the recipe. Although your team may not have used Conan, our recipes are pretty self-explanatory and declarative.

https://github.com/bincrafters/conan-abseil/blob/stable/20180600/conanfile.py

Of note, you can also find our CI files in the same repository (.travis.yml and appveyor.yml), which you might find interesting. We build with an extensive array of platforms/compilers/versions/etc, which might provide you additional build coverage on top of whatever CI you have internally. Again, the CI files are pretty declarative and straightforward to look at.

One of our long-term hopes is that, in time maintainers like your team will become more interested and involved, but that's for each maintainer to decide. Some have chosen just to advertise the Conan packages on their README for promotion purposes. As @uilianries mentioned, some projects such as the Flatbuffers team have chosen to accept the conanfile.py and CI files into the main repository, and we provide support for those. Another option is that we can simply transfer our conan-<project> repository on github to the organization of the library owner, and again provide long-term support while the ownership and control lies with the maintainer. This way it doesn't pollute your main repository or interfere with your CI, but still makes it an official part of the organization. This is perhaps the best arrangement from a public trust perspective, especially when the package is submitted to "Conan Center", the official and moderated central repository like Maven Central and Nuget.org. We hope this can happen soon.

In any case, the most important thing for us with high-profile libraries such as Abseil is starting a good dialogue with the maintainers so that you're aware of what we're doing, and can answer any questions that come up. At the very least, it makes it easier to chat with you about any future broken builds and share logs for troubleshooting, and you won't be blindsided by users who report they got the library through "Conan". Thanks for at least chatting with us, and we look forward to your feedback.

P.S. our team has a room in the official CPPLang slack channel. If any of your team are members there, please feel free to reach out to discuss. #bincrafters and #conan

[ahedberg]

It looks like the linked Conan file tracks our LTS branch, which feels sensible. I'm not sure what the version field would look like for a live-at-head project like Abseil, which doesn't put out versioned releases. Any thoughts on this?

[solvingj]

I almost included an explanation of this, but I cut it out because my response was already too long :)

We have a general post about it here, skip to "Packages without official releases", and the two sections after that:
https://bincrafters.github.io/2017/06/06/using-bincrafters-conan-repository/

And a specific post about Abseil here which also talks about it:
https://bincrafters.github.io/2017/10/04/Conan-Package-Abseil/

In summary, we should is to "bump" the version on some interval... maybe monthly, maybe weekly. We should use whatever date each bump falls on as the version number, and pin to the latest commit on that date. Then we should use Conan's "Alias" feature, and bump the latest version alias to point to the latest version. This could all easily be automated, however we lost our only full-time committer in March, and only recently are a few people on the team having the bandwidth to look at options for automation. Of course, we would try to automate it in a general way because we have many projects, making it a non-trivial endeavor.

We're looking at the new Github Actions feature for automating such things. One limitation we hit right away is that currently, actions can only subscribe to events within the organization owned. So, if your org owned the repository, you could trigger this automatically on every commit to Abseil, or perhaps new tags or something, but we could not. The desire to subscribe to events from "any" github project will certainly be going back to Github team, but that'll take a while probably. (I'm not trying to push it on you just yet, just pointing out this new fact we just learned).

Anyway, feedback welcome.