New procedure to modify operating-system records

New procedure to modify operating-system records

[Sergio Pastor Pérez]

Hello Guix.

Some time ago, I disclosed on this mailing list that I was working on a
procedure to facilitate modifications of Guile records. The idea was to
be able to easily apply transformations to all `operating-system` record
packages.

I received a lot of help from Michal Atlas and Juliana Sims. Both of
them are active members of this community, and I'm very grateful for how
welcoming the have been.

I'm writing this mail from a system that grafts `mesa` for the
`nvidia-driver` available in [1]. Although I'm aware that this is not
the place to discuss proprietary stuff, this is not about running an
NVIDIA system. This enables any Guix user to arbitrarily replace
packages system-wide. One could replace `glibc` for `glibc-custom`. I'm
using the NVIDIA graft as an example because it's what I have at hand
that would test that the graft applies system-wide effectively.

The procedure allows the user to apply a function to all elements of a
collection that match a certain type. With this new procedure one could
write something like this:
--8<---------------cut here---------------start------------->8---
(map-type
  (lambda (_)
    (@ (gnu packages games) cowsay))
  (@ (guix packages) <package>)
  my-operating-system)
--8<---------------cut here---------------end--------------->8---

Which will replace every package on the system for the `cowsay`
package. Albeit a cowsified OS will not be very useful, other kinds of
transformations could greatly simplify OS definitions. It would make it
very convenient to deploy systems with grafts on important libraries
that are dependencies of many packages. A more useful example would be
this syntax rule:
--8<---------------cut here---------------start------------->8---
(define-syntax-rule (custom-libc-operating-system exp ...)
  "Like 'operating-system' but graft 'libc' with the a custom 'libc'
package."
  (map-type
    replace-libc
    (@ (guix packages) <package>)
    (operating-system exp ...)))
--8<---------------cut here---------------end--------------->8---

Which, if `replace-libc` grafts your custom libc using
`package-input-rewriting`, would allow you to define a system like so:
--8<---------------cut here---------------start------------->8---
(custom-libc-operating-system
  ...)
--8<---------------cut here---------------end--------------->8---

Is Guix interested in having such a procedure? If not, I will submit it
to Nonguix but I believe it would be a welcomed addition for Guix users.

In the case that the Guix community is interested where should it be
placed? I was thinking `guix/records.scm`, what do you think?

The complete implementation can be found in my personal channel [2].

[1] https://gitlab.com/nonguix/nonguix
[2] https://codeberg.org/shepherd/omega/src/commit/0d45b10f709cfbc70c3ec756933f09a296a9d6e3/pastor/utils/gpu-specification.scm#L51


Have a nice day!
Sergio.

Re: New procedure to modify operating-system records

[Ludovic Courtès]

Hi Sergio,

Sergio Pastor Pérez <sergio.pastorperez@outlook.es> skribis:

> I'm writing this mail from a system that grafts `mesa` for the
> `nvidia-driver` available in [1]. Although I'm aware that this is not
> the place to discuss proprietary stuff, this is not about running an
> NVIDIA system. This enables any Guix user to arbitrarily replace
> packages system-wide. One could replace `glibc` for `glibc-custom`. I'm
> using the NVIDIA graft as an example because it's what I have at hand
> that would test that the graft applies system-wide effectively.
>
> The procedure allows the user to apply a function to all elements of a
> collection that match a certain type. With this new procedure one could
> write something like this:
>
> (map-type
>   (lambda (_)
>     (@ (gnu packages games) cowsay))
>   (@ (guix packages) <package>)
>   my-operating-system)

That sounds useful!

> The complete implementation can be found in my personal channel [2].

[...]

> [2] https://codeberg.org/shepherd/omega/src/commit/0d45b10f709cfbc70c3ec756933f09a296a9d6e3/pastor/utils/gpu-specification.scm#L51

My main concern with this approach is that it breaks abstractions.
Ideally, records would only be accessed through their public accessors
(which might perform additional processing, such as unpacking ‘thunked’
fields) and created by their public contructors (which might do things
like run field “sanitizers”).  We always (almost) keep record type
descriptors (the <angle-bracket> things) private also for this reason.

So while I think the feature is much welcome, I believe we should strive
for an implementation that doesn’t break abstractions.

As I mentioned earlier, one option would be to apply transformations at
the derivation-level: take the OS derivation and use ‘map-derivation’ to
map, say, the derivation of one package to another one.  The advantage
is that we’re guaranteed to not miss a single package; the downside is
that it’s low-level and might not perform well.

Food for thought!

Ludo’.

Re: New procedure to modify operating-system records

[Sergio Pastor Pérez]

Hi Ludo, thanks for taking a look!

Ludovic Courtès <ludo@gnu.org> writes:

> So while I think the feature is much welcome, I believe we should strive
> for an implementation that doesn’t break abstractions.

I agree. I would rather have a procedure which respects abstractions.

> As I mentioned earlier, one option would be to apply transformations at
> the derivation-level: take the OS derivation and use ‘map-derivation’ to
> map, say, the derivation of one package to another one.  The advantage
> is that we’re guaranteed to not miss a single package; the downside is
> that it’s low-level and might not perform well.

I didn't know about that procedure, seems adequate for the job. I'm
trying to experiment with it but it does not seem to behave as I would
expect. For instance, I'm facing this error:
--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> (use-modules (guix)
                                 (guix derivations)
                                 (gnu packages)
                                 (gnu packages perl)
                                 (gnu packages games))
scheme@(guix-user)> (with-store store
                      (let ((cowsay-drv (package-derivation store cowsay))
                            (perl-drv (package-derivation store perl))
                            (perl-5.6-drv (package-derivation store perl-5.6)))
                        (map-derivation store
                                        cowsay-drv
                                        `((,perl-drv . ,perl-5.6-drv)))))
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure fport_read: Is a directory

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guix-user) [1]> 
--8<---------------cut here---------------end--------------->8---

If you inspect the `cowsay` derivation, you will see that the mapping
should be possible since it contains the `perl` derivation.

Am I doing something wrong?

PS: Does `map-derivation` recurse into child derivations or the mapping
only affects the immediate fields of the derivation?

Have a nice Sunday!
Sergio.