starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00

[GH-ISSUE #171] Seperate proto definitions into seperate repo #116

New issue

Closed

opened 2026-02-27 19:28:55 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 19:28:55 +03:00

Owner

Originally created by @sashahilton00 on GitHub (Feb 27, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/171

Originally assigned to: @plietar, @sashahilton00 on GitHub.

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

Originally created by @sashahilton00 on GitHub (Feb 27, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/171 Originally assigned to: @plietar, @sashahilton00 on GitHub. 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 ```txt 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

kerem closed this issue

2026-02-27 19:28:55 +03:00

kerem commented

2026-02-27 19:28:56 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Mar 8, 2018):

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.

@sashahilton00 commented on GitHub (Mar 8, 2018): 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.

kerem commented

2026-02-27 19:28:56 +03:00

Author

Owner

@ashthespy commented on GitHub (Sep 28, 2018):

Would git-subtree be an alternative for this scenario?

@ashthespy commented on GitHub (Sep 28, 2018): Would [`git-subtree`](https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree) be an alternative for this scenario?

kerem referenced this issue

2026-02-27 19:59:57 +03:00

[PR #116] [MERGED] Jackaudio Support #786

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#116

No description provided.

Rows
Columns