Rename and exclude own package from dash check

[lukasmittag]

Rename the rust-sdk libraries to sdk-* and exclude them from dash license check.

[SebastianSchildt]

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 ?

[argerus]

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

[lukasmittag]

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

[argerus]

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 😄
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.

[SebastianSchildt]

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"

[erikbosch]

Looks good to me. @lukasmittag - I assume this one needs to merged before the newly added PRs, but I leave that to you