Hello Kurt, On July 18, 2025 12:14:12 PM GMT+08:00, Kurt Kremitzki <kurt@kwk.systems> wrote: >Hello all, > >I'd like to float an idea for an improvement to what's possible with package >transformations. This seems like it would be a good beginner contribution for >me (or anyone who might want to tackle it sooner!), but before I go ahead, I >want to invite feedback on my idea. > >Background >========== >I'm a Debian Developer getting started with Guix, so I figured I had better >orient myself by looking at the packages I'm already maintaining in Debian. In >my case, I wanted to get started by updating OpenCASCADE, a FreeCAD >dependency. > >Besides updating the version, I also noticed the Guix package is not using the >optional RapidJSON dependency to enable glTF export. Changing this is a matter >of including that package as a dependency and adding a CMake flag. > >Since this was my first time working with Guix packaging, I tried testing this >setup using only package transformations. However, quoting `guix package -- >help-transform`: > >``` > --with-input=PACKAGE=REPLACEMENT > replace dependency PACKAGE by REPLACEMENT >... > --with-configure-flag=PACKAGE=FLAG > append FLAG to the configure flags of PACKAGE > >``` > >So, it's possible to inject a configure flag, but not to inject a package, >only >to replace one. > >Proposal >======= > >I would like to amend the `--with-input` syntax to allow for both addition and >removal, for example in the case of testing optional behavior or seeing if a >dependency can be removed (imagine a `foo-minimal` variant.) I don't have any >particular preference for the syntax. >
I generally agree that adding and removing inputs via transformations could be a nice feature, but I don't think it is suited for with input transformation. The with input transform is actually a 'replace PACKAGE with REPLACEMENT' type of transform. Then when you build a package, let's call it TARGET, if that package transitively depends on PACKAGE, it will get replaced with REPLACEMENT. This is sort of an indirect modification of TARGET. What you are suggesting is to modify the TARGET directly, not indirectly. That means the transform would take TARGET and add/remove from its inputs. Thus I think this is better suited for a new transform argument maybe even multiple - This is because I am not sure if transformations support anything else than `<package-name1>(=<package-name2>)?` arguments. Maybe it could be useful to also support replacement of input of TARGET directly, non-transitively. >For the sake of symmetry, I also wonder if it would make any sense to allow >for removal of a configuration flag. Depending on the build system, it may be >that appending e.g. `foo=off` will supersede an earlier `foo=on`, which would >mean the existing `--with-configure-flag` behavior is enough. I don't plan to >work on this change, but thought I should just mention it. > >Anyway, thanks in advance for your feedback! > >Cheers, >Kurt Rutherther > >
