Seperate proto definitions into seperate repo

[sashahilton00]

This is just a tracking issue for a discussion about how we should handle the proto files, as they are now in use by multiple projects. Here is a copy of the chat from Gitter:

Sasha Hilton @sashahilton00 Feb 26 03:09
indeed it should. Will discuss tomorrow. It might not be a bad idea to put the proto files in a seperate repo so that we can update once, update everywhere so to speak. @xplodwild @plietar @awiouy thoughts on moving proto files to something like librespot-protobuf and having it as a submodule for each of the projects?

Paul Liétar @plietar 01:28
There are two options, the first one is to have the librespot-protocol crate in the new repository and published on crates.io, and librespot-core depends on it through cargo. This way there wouldn't even be a need for git submodules

Sasha Hilton @sashahilton00 01:32
how would that allow versions of librespot written in different languages, such as librespot-golang to receive the updated proto files though? what I was thinking is that only the .proto files would be in librespot-protobuf, but then there is the question of the tradeoff that one makes for people building librespot (requires them to have protobuf installed and protoc-rust-gen plugin set up whenever they want to build...). Not sure there's a clear solution to this one, perhaps something that should be revisited at a later date?

Paul Liétar @plietar 01:32
The second is to only have the protocol/proto directory of (rust) librespot be in the submodule and keep the same mechanism as today to generate the Rust definitions, ie the protocol/build.sh file and check in the Rust generated code in the rust librespot repo

Sasha Hilton @sashahilton00 01:33
sorry, responded prematurely. Your second option was the one I had in mind, but I'm not sure the tradeoff of requiring people to install protobuf and set it up for rust is worth it, given the frequency of protobuf updates.

Paul Liétar @plietar 01:34
This wouldn't change anything, the generated rust code is still checked into the rust repo

Sasha Hilton @sashahilton00 01:36
true, but in the event one updates files in the proto repo, librespot isn't going to automatically regenerate the rust code. This isn't necessarily a problem, it just means that one has to remember to rebuild the protobuf rust bindings when updating the proto repo.

Paul Liétar @plietar 01:37
For the first option, the layout of librespot-protobuf repo would be something like

librespot-protobuf/
|- src/
    |- metadata.proto
    |- spirc.proto
    |- ....
|- rust/
    |- Cargo.toml
    |- build.sh
    |- src/
        |- metadata.rs (generated)
        |- spirc.rs (generated)
        |- ...
|- go/
    |- whatever go needs/generates

Git submodules need explicit updates anyway, so at the same time you update the submodule you would manually regenerate the code
Using build.sh

Sasha Hilton @sashahilton00 01:39
true. I'd prefer option 2, as it feels like having all the librespot related rust code in one repo makes more sense than having parts of it in a different repo

Paul Liétar @plietar 01:39
Yeah I agree
But on the other hand I very much dislike git submodules

[sashahilton00]

As a possible halfway house to this, what a quick and dirty solution to this could be would be for me to write a bash script that runs the usual build commands, and retrieves/updates submodules as necessary. I'm not a fan of them, but having a pseudo-seperate repo with bits of the rust code that librespot uses doesn't feel like a good solution.

[ashthespy]

Would git-subtree be an alternative for this scenario?