Indeed those are interesting topic but as mentioned by @waffle8946 these are out of scope for the RFC.
About 1. Package Overrides as a Use Case did you know some modules allowed you to override the package? Like this one.
Is that because youāre not looking to design a generic interface/implementation mechanism? It just felt like another use case to inform the design if that was the goal. But perhaps you were thinking about something much more specific? To me, your interface idea looks in principle quite generic and not limited to services, and Iād be delighted if the same mechanism could be applied to different domains. But, sure, it also makes sense to focus on a specific use case if thatās what you are looking to solve.
And in any case Iām happy about this proposal, because I think more thought out software engineering methodology is what Nix needs. 
Yes, but we havenāt demonstrated this idea for services yet. Of course work can be done in nixpkgs in parallel, but thatās a whole other discussion to be had there. Adding that to this RFC means more to bikeshed about, at least from past observation.
2 Likes
If we can solve more issues even with this RFC, I would be delighted. But I donāt see at all how it could be applied to the problems you described. If you have any idea I would be happy to hear it!
Indeed the goal is to decouple services - modules in nixpkgs - using structural typing.
3 Likes
Ah, now I see what you mean! I wasnāt suggesting adding those use cases to this RFC (I agree that wouldnāt be a good idea)ājust that keeping additional use cases in mind might help refine the abstractions further. By thinking about corner cases from other domains, the resulting interfaces could become even neater and more versatile. To be clear, Iām not looking to hijack this RFC or propose competing ideas.
Fair enough! I think Iāll have to flesh out applying this to the cases I mentioned a bit more.
Perhaps I can clarify where Iām coming from.
The motivation for my thoughts comes from experiences with Nix the language, nixpkgs, and NixOS. Package overriding felt like an example that I encounter often, but it may have been more misleading than helpful. (I hadnāt even thought about NixOS modules, which perhaps underscores that Iām not communicating very clearly. 
) In general, a lot of what feels incoherent to me seems to stem from the lack of tools to encourage structural typing or coherent interfaces. Without these, the path of least resistance often leads to ad hoc solutions.
So my thinking isnāt primarily about āmaking package overrides easierā but about encouraging some sound software engineering principles and providing tools to support them, primarily structural typing, contracts and the subsequent ability to test components in isolation (Iāve actually framed it more as Haskell style type classes, but I think thereās no big difference). I believe approaches like these will demonstrate their value when applied, and I hope people will over time apply them to other parts of the ecosystem, making everything more maintainable and cohesive.
This is why Iām excited by your RFC from a general perspective; I hope it will have a ripple effect beyond service decoupling.
4 Likes
Iām excited because all the comments so far are really positive. Thank you all for that!
If you see some issues, speak up! If not, Iāll be writing the real RFC soon with an accompanying draft PR.
6 Likes