On 2025-04-05 09:38, Ian Eure wrote: Hi Ian, thanks for this discussion.
This is my (d) (better policy proposition): > a) Leave it as is. Don’t love it, but if there’s concensus that > this is the right way, then okay. 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. (This is the case where not having the binary is absurd because it renders the emacs package unusable). > b) Make packages that align better with specific usecases, > ex. emacs-emacsql-sqlite, -mysql, etc. This feels fraught to me, > and I don’t think it works if you get emacs-emacsql-sqlite as an > input to some other emacs-* package, but want emacs-emacsql-mysql > as a user. Perhaps metapackages which only exist to combine > dependencies would make this a workable approach. > > c) Don’t set them at all, and use the same $PATH late binding as > is typical of other Emacs setups. This would mean that > installing Emacs packages wouldn’t Just Work, and users would > have to install the inferiors (and know what packages those are > in) themselves. IMO this is the best solution when it's not an "essential binary" : Maybe when the package properly signals the absence of the desired input to the user AND the package behaving properly as soon as it's in a profile is enough (and we wouldn't need to ensure inputs in this case). This means that we could participate in emacs packages by improving their management of missing binaries, so that we can ensure normal guix use with smaller profiles. > d) Have some better policies around when to use inputs and when > not to. This might be the most pragmatic approach, though it > means inconsistency from package to package. > > e) Build a suggested package mechanism into Guix. This has been > floated a couple times before. If it defaults to not installing > suggested packages, but telling the user about them, this would > be like option C, but making it easier to find which packages you > might need; if it installs them by default, it would work like > the current setup, but give users some kind of out to avoid the > extra bandwidth/disk usage. I don’t know how this would work for > declarative package setups -- how would I express to Guix Home > that it should install emacs-emms with flac (for metaflac), but > without mpg321, vorbis-tools, and mp3info? 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. In summary : Is the input essential to the core functionality of the emacs package? + Yes: (a) + No: Is the package signalling the absence of its input in a Guix-understandable way? Does adding the input fix the issue? - Both yes : (c) - At least a No: Submit a patch to the upstream package to ensure both yes. -- Best regards, Nicolas Graves
