But including this in your own Emacs as a consumer of the flake becomes quite hairy, particularly if you don’t want to hard-code those dependencies in the calling form:
I’d be pretty interested to see an example of how to write that overlay because I agree it would be nice, but there are quite a few locations in nixpkgs where you can find the emacs packages set. It’s diretly on nixpkgs, it’s on individual emacs builds, etc. I didn’t try very hard to be fair but there was no “obvious” way to do it.
The lack of architecture is a feature in this case. Emacs code is architecture independent.
I have a feeling the same thing holds for python, haskell, etc? How are those published through flakes?
I looked a little into it, I agree it’s tricky. In theory there should only be a single nixpkgs attribute that needs to be adjusted, though, since all other uses of it should come from callPackage args and therefore be modified by an overlay.
For other languages it’s less complex to my knowledge, since they don’t need to be tied into the ecosystem via a system-wide init file, so you can pretty easily just add a new package normally.
On reflection: doesn’t this approach mean that we (people who publish emacs packages as flakes) are all vying for the same namespace? I thought the whole point of flakes was to solve that.
I’m starting to feel like flakes are actually a step back for anything that isn’t a precompiled binary. Is there any official guidance on this issue, do you know?
The approach outlined by the Automatic package management on the Emacs page of that wiki does mean you get an attribute set (where the attribute names are a namespace), sure.
It’s also possible to build an emacs with an emacs package from a flake without overriding epkgs.