Closed lukasmittag closed 8 months ago
I understand how this solves the dash generation issues. In terms of "nameing" the packages, I have no opinion whether that is good or bad, or doesn't matter at this point anyways.
I.e. in the future is some work done in what is called SDK now, a candidate for ebing moved out/published as a standalone cratte that could be used by others? If so, how should that be named, and would it already be useful to name things accordingly now, or are we just not there yet?
Any opinions @argerus @lukasmittag ?
I.e. in the future is some work done in what is called SDK now, a candidate for ebing moved out/published as a standalone cratte that could be used by others? If so, how should that be named, and would it already be useful to name things accordingly now, or are we just not there yet?
Going by how packages/crates are usually named in Rust, I think having kuksa
as the general prefix would be better. That way we avoid any risk of clashing with the names of other crates out there.
For libraries/binaries that are only used internally, we don't need to prefix them with kuksa (but we could), but for things that are to be published as crates we probably should do that.
For example:
package name | type | published as crate | comment |
---|---|---|---|
kuksa |
library | Yes | The client library |
kuksa-databroker |
binary | Yes | databroker |
kuksa-proto |
library | No | protos & proto lib |
Yes, so the intended structure would be: | old | new |
---|---|---|
databroker | kuksa-databroker | |
databroker-proto | kuksa-databroker-proto | |
databroker-cli | kuksa-databroker-cli | |
databroker-examples | kuksa-databroker-examples | |
sdk-kuksa | kuksa-sdk | |
sdk-sdv | kuksa-sdk-sdv | |
sdk-common | kuksa-sdk-common |
or only prefixing the last three kuksa-sdk-*
since databroker is a binary and not intended for external use?
would this fit for you? @argerus @SebastianSchildt
or only prefixing the last three
kuksa-sdk-*
since databroker is a binary and not intended for external use? would this fit for you? @argerus @SebastianSchildt
I think databroker is intended for external use :smile: Publishing a binary to crates.io gives a quick way to install by:
cargo install kuksa-databroker
This makes even more sense for the cli.
cargo install kuksa-cli
which IMO should just be called kuksa-cli, without "databroker" as that doesn't really add any useful distinction.
old | new | comment |
---|---|---|
databroker | kuksa-databroker |
|
databroker-proto | kuksa-proto = "../kuksa-proto" | Local dependency, not a crate |
databroker-cli | kuksa-cli |
|
databroker-examples | - | Should probably just be a folder under kuksa instead of a package |
sdk-kuksa | kuksa |
Do we really need to include the term "sdk"? |
sdk-sdv | kuksa-sdv = "../sdv" | Local dependency, not a crate |
sdk-common | kuksa-common = "../common" | Local dependency, not a crate |
EDIT:
So in summary.
One (library) crate: kuksa
.
And two binary crates: kuksa-databroker
and kuksa-cli
.
I think kuksa - without sdk - is fine as a crate name, i.e. it wudl be weird to have a crate called sdk, wheter at a later point (i.e. if, when we mightl split it out in case it is practical) call a repo kuksa-rust-sdk is a different question (i.e. similar as currently the rpos is called "kuksa-python-sdk" whereas the installable lib is called "kuksa-client"
Rename the rust-sdk libraries to
sdk-*
and exclude them from dash license check.