Structure of addons / plugins etc.

[dirvine]

I was looking at the library and wondered the future direction in terms of adding new devices and device types? I am looking at adding support for https://github.com/adafruit/Adafruit_Python_PCA9685.git as an example. It is a PWM board so not a sensor as such. This lead me to wonder should these be included in this lib or separately and include the lib to create them or some other approach, like separate crates per device type itself.

I have no preference or real suggestion at the moment, but notice many python modules are just released as modules by vendors etc. I also love the idea of alib that bundles all of these together as it must be much simper for users. Anyway I would welcome any guidance on this one.

[posborne]

In general, I think I would lean toward having the devices live in a separate crate (which we would be happy to link out to). The ones present were an extension/generalization of the examples I started with. At this point, it might make sense to pull them into a separate crate (which could contain multiple drivers). I see little downside in having single crates for drivers (apart from some difficulty with fragmentation/discovery).

[dirvine]

Sounds good, would you think a naming convention would help so something like
i2c-<device> as crate names? Sorry to be a pain, but this is a great chance to get a system that helps all newcomers. BTW huge thanks for the work so far.

[posborne]

No problem. Wish I could be devoting more time to this, but things have been busy at work and on other projects lately, so i2cdev hasn't gotten much love.

I think the i2c-<device> naming convention seems reasonable. This relates some to conversations on how to write device drivers using traits here: rust-embedded/wg#19. That discussion will probably take some time to get anywhere and I don't think it should necessarily hold up getting code into the wild.