Hi Sergio,
I've moved domain names, the final post is at https://blog.coldboot.org/parameterized-packages-the-project-completion-update.html You can find code for the project in this repository: https://notabug.org/cel7t/guix-parameters Additionally, the project completion report: https://github.com/matchcase/parameterized-packages.org I haven't been able to make an issue for this project because I'll need to update bits of the code to ensure that it is working smoothly before creating an issue and unfortunately I'm a bit occupied at the moment as I'm writing my graduation thesis. Best, Sarthak. On Sun, 6 Apr 2025, 19:16 Sergio Pastor Pérez, <sergio.pastorpe...@gmail.com> wrote: > Liliana Marie Prikler <liliana.prik...@gmail.com> writes: > > Am Samstag, dem 05.04.2025 um 09:38 -0700 schrieb Ian Eure: > >> Hi Guixers, > >> > >> I’ve seen a few patches for Emacs packages lately which have the > >> form: > >> > >> (package emacs-whatever > >> (name "emacs-whatever") > >> (description "Emacs interface for Whatever") > >> (inputs (list whatever)) > >> (arguments > >> (list > >> #:phases > >> (modify-phases %standard-phases > >> (add-after 'unpack 'set-whatever-path > >> (lambda (#:key inputs #:allow-other-keys) > >> (emacs-substitute-variables "whatever.el" > >> ("emacs-whatever-program" > >> (search-inputs-file inputs > >> "/bin/whatever"))))))))) > > Side note: the ordering of fields here looks rather displeasing. > > > >> ...and looking in emacs-xyz.scm, many packages do this. I > >> understand why this pattern exists -- making the inferior an input > >> means that installing the Emacs package Just Works -- but it also > >> means increased disk consumption and somewhat less user > >> flexibility. > >> > >> On the flexibility side, it means that if you install > >> emacs-whatever and my-personal-whatever-fork, emacs-whatever will > >> continue using the stock whatever, not your fork; making this work > >> requires transforming emacs-whatever to replace the input. I > >> think that because this behavior is so different from how most > >> other operating systems work, it’s surprising, and the solution > >> isn’t obvious. > > You obviously can still customize it to use a PATH lookup. You are > > wasting disk space if you do so. Alternatively, input rewriting such > > as the --with-input command line flag replace whatever with your- > > personal-whatever-fork and thus do exactly what you want. > > > >> […] > >> I’m not sure how to do that, though. I can think of a few > >> options: > >> > >> a) Leave it as is. Don’t love it, but if there’s concensus that > >> this is the right way, then okay. > >> > >> 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. > >> > >> 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? > > f) Implement parametrized packages 😉 > > Hello! > > Do you know where can we find the parameterized packages code? The > original blog that documented the developments has been down for a long > time now. > > [1] https://blog.lispy.tech > > The author, Sarthak, said that an issue will be opened to track the > developments, but I'm not aware if it has already been created. > > > Best regards, > Sergio. >
