Separate sensors into other crate

[Kixunil]

I believe that sensors are higher-level stuff, which should use i2c crate as their dependency. It makes little sense to pull also code for sensors if somebody wants to use just i2c.

BTW, regarding this issue and the others I filled, I'm willing to help with code, if you agree. I already have some code (open and io traits). (I didn't realize that I2C library already exists when I was writing it.)

[posborne]

I agree on this one. The sensors present evolved from examples and were my fleshing out ideas as to what these drivers might look like. Do you think having the crate in the same repo makes sense or a separate Github repo?

[Kixunil]

I would personally prefer separate repo.

[Kixunil]

I've started working on separate repo for i2c-devsensors. I decided to make each sensor a separate crate within common repository.

That brings me to question: what to do with sensor traits? I could put them into i2cdev-sensors crate but I think a better idea would be to create a separate crate (called sensors), because the traits technically don't necessitate use of i2cdev. This way one could e.g. implement Thermometer for DS18B20 which connects over One-wire.

What do you think?

[MrSpock]

I believe there should be separate sensors crate with misc devices in it. Many devices you can access over I2C and SPI, so in future you can select connecting interface by feature/cfg stanzas.
That decision would be usefull since I'm starting writing another library for range sensor (VL53L0X) and I'm wondering if I should create separate create or make pull req here :)

[tadeegan]

@Kixunil The problem with what you have done is that you wiped all the git history so the authors who created these plugins no longer attributed to their work. A separate create named "sensors" containing only interfaces SGTM.

@rust-embedded Can we move the repository under your namespace?

This is taking so long.....

[Kixunil]

OK, I'll look into creating sensors crate, hopefully today.

@tadeegan good point. How do you think I should attribute their work? Is linking the original repo sufficient? Or should I clone the original repo and build the new one on top of it? (That'd be more work.)

[Kixunil]

@MrSpock I believe the crate should be separate but repository might be the same. It depends on amount of code - if there is a lot of code, I'd prefer separate repo.

[posborne]

@MrSpock I believe the crate should be separate but repository might be the same. It depends on amount of code - if there is a lot of code, I'd prefer separate repo.

Let's start with the same repo approach for the core platform support and traits. That can be easier to manage as well -- if we separate out the crates properly people can still have separate crates in separate repos as well.

If that doesn't scale, we can pivot.

EDIT: I'll try to look at where things are at a little bit more and may update this proposal a bit. I can definitely get more repos added here as required but would prefer too much churn in repos as the Org should mostly contain things that are a bit more canonical.

[tadeegan]

https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/

@posborne SGTM.

[Kixunil]

Ping! @martindeegan and @tadeegan did a huge amount of work in a PR against my repo. I'd like to unblock them.

Unfortunately, I don't have much time these days, but I'd help with minimal things. I can also handover the repo or whatever is needed.

Things that we need to resolve:

• How to name traits crate. I strongly favor sensor-traits (in the spirit of num-traits).
• How to attribute original authors. If someone wants to retain the history, please do it yourself - it's too much work for me now and I have full time job + another (embedded Rust but w/o i2c) project + I want some social life to not become crazy :)