You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some tooling (e.g. bazel) would benefit from official standalone binaries for the protoc plugin. Would the project be open to building & hosting these kinds of artifacts? A github action centric approach (PoC cbracken/rules_dart#59 (comment)) might be a good MVP viable for most use-cases.
The text was updated successfully, but these errors were encountered:
hello this subject is very interesting, googleapis repo uses their own generators, usually each made in the language it generates, they use some magic to avoid "binaries" using http_archive references into repositories with a structure that builds(works in linux/mac) them within the pipeline, and then the repository_rules file has the different tags the buildfile_generator will use to create a centralized buildfile.bazel with all the targets for the diff languages, I think if you could make the protoc-generator plugin as a separate github repo and replicate python or other generators repositories.bzl,BUILD.bazel,rules_dart/BUILD.bazel...
It would be awesome if we could have dart added to the list
as other users mentioned in other issues, the task surpasses my skillset widely ftm
Some tooling (e.g. bazel) would benefit from official standalone binaries for the protoc plugin. Would the project be open to building & hosting these kinds of artifacts? A github action centric approach (PoC cbracken/rules_dart#59 (comment)) might be a good MVP viable for most use-cases.
The text was updated successfully, but these errors were encountered: