Something needs to be done about the prelude

[jessebraham]

To start, I know the prelude module can be kind of contentious in general; however it's always been my view that it is entirely opt-in, so if you have an issue with it don't use it, and it's still available for people who do want it. I also get annoyed having to constantly import traits, or needing every project to include eg.) embedded-hal, which the prelude helps with.

However, there are increasingly more issues with the prelude as we continue to develop the HAL. For example, for awhile now the prelude::eh1 module has just been completely broken, I'm not sure if it ever worked correctly to be honest. There are a number of instances in examples where we need to specify the trait anyway as well, due to conflicts.

So, given our issues I'm soliciting input on this. My feelings have already been stated however I am happy to change them if it better suits what the community wants.

One last thing I will mention, is that I think we probably use too many traits in our peripheral drivers currently and I think a lot of these can be eliminated via refactoring. The fewer traits we publicly export the less of a need for a prelude there is.

@MabezDev @bugadani I know you both have mentioned issues with this to me personally, so please feel free to chime in.

[bugadani]

My previous experience is that preludes tend to work well for smaller libraries, where you'd import half the library anyway to use it, every time you use it. For a HAL, this would probably translate to one prelude per peripheral/module. A global prelude is probably a good way to collect a bunch of conflicts, similar to what happened here.

I'm not sure what a prelude should/shouldn't actually contain and how esp-hal should be refactored, that would need more thought. But I'd definitely like to avoid including traits that immediately conflict with each other :)

[MabezDev]

I think having our prelude just export traits from inside esp-hal-common should be okay, and maybe embedded-dma & fugit too. Imo we shouldn't be re-exporting any embedded-hal stuff at all, we should instead:

• Provide concrete methods on the various peripherals so you can use the peripheral without the trait imported
• Only import the e-h traits in examples where we really need to be generic, AFAIK we don't have any examples in the situation yet.

[bjoernQ]

I might be wrong but I think e.g. embassy doesn't provide preludes at all. It's for sure opt-in but if it's causing issues for us, we should really challenge if it's worth it

[jessebraham]

We have to do a lot of work eliminating unnecessary traits in our peripheral drivers to make them remotely usable wtihout needing to import dozens of traits in applications. I have started on this but it's going to take some time.

[jessebraham]

#860 begins work on removing trait re-exports from the prelude, as well as fixing the SPI issues I inadvertently introduced.

[jessebraham]

The remaining task here is to remove the remaining embedded_hal traits from the prelude, however:

1.) This will require updating a number of peripheral drivers to be more usable without embedded-hal
2.) All of the examples need updating, which is quite the undertaking

I am actively working on this but it will take some time I'd imagine.

[jessebraham]

Once we publish our next release next week, I will work on feature gating the embedded-hal@0.2.x trait implementations, and then finally remove these traits from our prelude. I think once that's done we can finally wrap this up.