On 2025-04-05 16:55, Ian Eure wrote: >> I'd argue sometimes it's indeed the better solution, especially >> when >> the core of the package needs the binary to work properly, not >> when it's >> an additional option or feature. I'll refer to that as >> "essential >> binary" in the rest. > > I appreciate this line of thinking, but suspect that whether a > binary is essential or not depends on the user’s usecase, which is > unknowable at package build time. For a user using EMMS to play > MP3s, flac isn’t essential, and mpg321 is; for someone using it to > play FLACs, the inverse is true. > >> (This is the case where not having the binary is absurd because >> it >> renders the emacs package unusable). > > I think it’s important to distinguish between "unusable" and "not > usable unless the user takes some action."
In those cases, maybe we could have -minimal variants? >> I agree this is nice, but maybe it's enough to do that in Emacs >> packages >> themselves (ensuring they suggest the missing binary when it's >> not >> found) rather than in Guix Home itself. > > I also like this idea; do you have an idea what an implementation > for that would look like? Presumably upstream package authors > wouldn’t want Guix-specific stuff in packages that need to work on > any OS/distro. Indeed, I don't mean plainly writing "Guix profile" in Emacs packages, but ensuring for instance that we have a proper error message explaining that the package is not in the PATH. I guess something like "Unable to find xxx, ensure it is installed on your system." is clear enough. A recent example that happened to me (not a binary though but a guix-related bug): https://github.com/anticomputer/age.el/issues/15 was fixed with https://github.com/anticomputer/age.el/pull/16/commits/a1c9d0a7911e603e6574daf1ee6d602d1e932842 Not writing "Guix" anywhere, but it makes it clear that something is missing on the system. -- Best regards, Nicolas Graves
