Hi, >making this work requires transforming emacs-whatever to replace the >input.
Yeah, but that's what you have to do with anything else in guix. You just need to invoke guix ... --with-input=mpg123=someother or use options->transformation in a guix home scm file for the same effect. It does replace any transitive dependencies with that name, too. (For comparison, I currently have 20 such options->transformations calls--7 of those for emacs packages) >Another example is emacs-plantuml-mode, which has plantuml as an >input, which has icedtea as an input -- meaning an install of the >Emacs package comes with a whole Java runtime. Well, if it doesn't work without then that is exactly how it's supposed to be. That Java runtime will be deduplicated anyway, though. It's also just a *specific* plantuml version that is supported by emacs-plantuml (since they communicate, they have to use a common protocol). And plantuml depends on the Java version that it was tested with. And different openjdk major versions ARE (slightly) incompatible, for example. So openjdk *absolutely* should be a regular input of plantuml, and plantuml should be automatically wrapped so it does use that. For the same reason, plantuml should be a regular input of emacs-plantuml. >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. In the end it depends on what kind of program the other program is. If it's an implementation detail (something conceptually inside the black box of the emacs-* package) then it should be a regular input. It should NOT be taken from PATH or in any other way late bound then. If we did late bind it that would just cause compatibility and usability problems. But if it's just a loose optional program that would conceptually be outside the black box of the emacs-* package and be in its own box, then it should just be picked up from PATH--or in an ideal world it would be activated via a dbus service in the first place, with an official interface (!!). Those are fundamentally different things in system design. It's not specific to emacs or anything. The disk space stuff would be better solved by parametrized packages. But that kind of dependency combinatorics would have fallout. It would cause packages not to build--see Gentoo USE flags and what happens when you use those (breakage... so much breakage)--and you would have a (exponentially) bigger amount of substitutes. I say that even though I'm low key bothered by the large amount of disk space that guix needs for stuff that I will never use. But there are tradeoffs. Optimizing for disk space would open another can of worms (combinatorial explosion). As it is, I just buy a way bigger drive than I would need for my data, for an extra $40. And if I wanted programs to invoke random executables I happen to have lying around, I could just use Debian. I was there--and it's not reliable to have this kind of global namespace in the wild west that is the free software ecosystem (this kind of thing creates a massive amount of inofficial interfaces--guess how long those are stable if none of the involved people know that the interfaces exist).
