argerus
commented
1 year ago Not optimal as I see it.
Could you articulate why this is a problem.
While I agree that there should be a clear place for the "master" version of these files (which is already the case, right?) I think it would be a mistake to:
- Remove local copies from other repositories.
- Adding a download step as part of any build process.
Even though this sounds good in theory, I've only had bad experiences with it in practice.
For example, automatically updating .proto files used in downstream projects requires manual updates to the code anyway. Using submodules is a lot more cumbersome than using a plain git repo (when you start merging / rebasing etc). And it's always easier to work with local files in a build process than getting a download step working correctly.
A better approach (in my experience) is to make it easy (as in automated, but manually triggered) to update local copies from the "master" version.
EDIT
I'm probably mostly against any automatic download of .proto files (as part of the build process). Automatically downloading certificates might make sense, but the arguments of added build complexity still applies.
erikbosch
Today the proto files in this repository exists as copies in other repositories like:
Not optimal as I see it. I would suggest that the APIs are moved to a separate repository, or possibly even multiple repositories, one for each API. That way the versioning/tagging of the Proto files could be handled separately from other items in this repo. Other repos could then include them as a submodule, or fetch them as part of build process.
(Similar arguments apply to default/example tokens/certs/keys)