Attila Lendvai schreef op do 13-01-2022 om 09:55 [+0000]:
> thank you Maxime!
> 
> with your guidance, i have managed to add guile-srfi-189 next to
> the other guile-srfi-NNN packages in guile-xyz.scm (a slightly tested
> diff is attached).
> 
> but when i grep for how these guile-srfi-NNN packages are actually used
> within guix, then i don't see any hits unfortunately.
> 
> i tried the following to do a quick test of my new package:
> 
> $ ./pre-inst-env guix shell guile-srfi-189
> $ ./pre-inst-env guix repl
> scheme@(guix-user)> ,use (srfi srfi-189)
> While executing meta-command:
> no code for module (srfi srfi-189)

Using the guile REPL is a little less complicated than the guix repl,
I would recommend trying
"./pre-inst-env guix shell guile-srfi-189 -- guile" first.

> 
> how do i introduce it into the guix codebase, without breaking e.g. bootstrappability?

Take a look at ‘2.2  Requirements’ in the manual:
at least for now, I would recommend that the SRFI is kept optional
(using #:autoload and the like) and only required when doing Guix
System things, to help people bootstrapping Guix from a foreign distro
(without the binary installation, albeit with the bootstrap seeds).

See <https://issues.guix.gnu.org/52742> for how guile-lzma was added as
dependency, or see 67bf61255414115ffae0141df9dd3623bc742bff for
guile-disarchive.

For bootstrappability, you might have to define a copy of
guile-srfi-189 in build-aux/build-self, as done for guile-gcrypt.
Whether this is necessary or not depends on where srfi-189 is used. 
IIUC, if it is needed to compute the derivation of the guix package,
then it is, but otherwise, it is not.  Because it is only used in (gnu
services ...) and not, say, (guix packages), I don't think is
necessary.

However, it would be best to check.  E.g. you could commit the
guile-srfi-189 package definition and your changes to (gnu services ...),
then do

$ guix time-machine --commit=a-commit-from-before-the-srfi-was-packages -- time-machine --disable-authentication --url=/the/checkout --commit=the-commit-in-the-checkout --version

i guess i need to add it as an input and a propagated-input to the
> guix package in package-management.scm? and then progress a kind of
> bootstrap stage/step, so that i can then `#:use-module (srfi srfi-189)`
> it in configuration.scm?

Adding to both inputs and propagated-inputs doesn't have any additional
effect, adding it to propagated-input should be sufficient.

probably by recording the new input as a commit, and then guix pull'ing
> it into my user's profile? and only after that can i start using it within
> the guix codebase?

(FWIW, ~/.guix-profile and ~/.config/guix/current are different profiles)

Personally I wouldn't clutter ~/.config/guix/current with changes
to a local checkout and I would use "guix time-machine" or "guix pull --root=..."
instead, but that's a possibility.

Because guile-srfi-189 is not yet among the inputs,
you will have to do "guix shell -D guix guile-srfi-189" instead
of "guix shell -D guix" to set up a development environment.

That won't work yet because the SRFI isn't upstream yet,
but that can be circumvented with '-e ((@ (guix packages package) (name ...) ...)'.

if that is the case, then is there a simpler/shorter way to test my new
> guile-srfi-189 package before i go through all this dance?

FWIW I think it's easiest to first package the SRFI, submit it
and wait for the patch to be merged.  Adding new inputs to Guix
is complicated enough as-is.

Greetings,
Maxime.