Recently, I came across the idea of opening an RFC to formally declare a methodology to deal with packages which provide multiple versions (eg. GCC, Java, LLVM, etc.). This comes after I redid how LLVM was providing multiple versions and after applying this to Zig (still in the works). If anyone wants to co-author the RFC with me, please feel free to reach out. I’m on Discord & Matrix.
16 Likes
I’ve got a few packages which would benefit from this – notably, all the Android devtools, Dwarf Fortress, and Armagetron. It’s not always practical to package multiple versions, but when it is, it should definitely be standardized because we do it differently everywhere. So count me in! 
3 Likes
I wanted to pitch it at the time, but it was still very new, but I want to pitch it now.
The Darwin SDK pattern uses overlays to organize code by functionality. Features can be toggled by including or excluding various overlays in the final list passed to lib.composeManyExtensions. I looked at other schemes for the SDK refactor, and they all read worse or hurt maintainability.
4 Likes
You very much can pitch in, Morgan (@numinit) and I haven’t worked on it in some time but I’m sure we can include you in some way.
2 Likes
Help is welcome! @reckenrode I believe you’ve been maintaining Foundry (which I appreciate, and use) and had to deal with something very similar.
2 Likes
I do. It probably should be refactored to follow the Darwin pattern. It’s got some additional constraints like supporting every version ever just in case someone wants to pin, but I think it could fit.
2 Likes
I don’t think an RFC would be the best way to go here. I think that not because this isn’t an important problem to think about but because I don’t think that we have sufficiently narrowed down the solution space for multiversioned packages to a point yet where we can decide on which solution is generally the best.
RFCs have an expectancy of permanence; that the solution chosen will be the best solution for a good while and at least a very good solution for a long time after that.
RFCs are also typically written are on problems where deciding on a subset of the solution space is critical; where coordination is required. In this particular problem, I don’t think there is a great need for coordination because packages are quite abstract pieces of software that offer a great amount of encapsulation; it doesn’t much matter to external users of the package which approach is chosen, they’re quite interchangeable.
Another purpose of RFCs is also to research and document solutions to a problem though and this would be very helpful here indeed. I think a better goal for you could be to produce a piece of Nixpkgs contributor manual on how to best do multi-versioned packages; describing and discussing multiple approaches.
If we were to later find a better approach or find that one of the approaches recommended has major flaws, it’d be trivial to change to the contributor docs to reflect those facts but it’d be a great hassle to update an RFC.
1 Like
We were actually mostly taking the “demo before RFC” approach. I think there’s a repo with one of our attempts under @djacu’s namespace we were all messing with. Now that there’s some renewed interest, we probably should publish it and get feedback
5 Likes