Split out protoc package?

[jakirkham]

There are some use cases for protobuf where only the CLI protoc is needed. In these cases the library is unneeded (or not needed as a direct dependency). Really what is needed is a CLI package that can be installed by the user or in the case of a recipe in build. This could also be excluded from migrations (as long as there are not format changes)

Am curious to know whether there is appetite for a change like this among maintainers. Also whether there are things to consider when making such a change. Thoughts? 🙂

[h-vetinari]

This is possible packaging-wise (and something @xhochy already brought up long ago); we could call it protobuf-compiler or protoc or whatever we like.

W.r.t. format-changes, it's clear that we'd need a libprotobuf that's at least as new as the compiler, but I'm not 100% sure that protobuf is always forward-compatible?

In short: not against the idea, but someone needs to check what constraints we need to follow to make this not break.

[xhochy]

I did exactly that for thrift as there the compiler itself is massive in size compared to the lib: https://github.com/conda-forge/thrift-cpp-feedstock/blob/a32005d71171846f180bddffe78099e670a4bdcf/recipe/meta.yaml#L99