Email or username:

Password:

Forgot your password?
Ludovic Courtès

#Guix packagers: you may like these new REPL commands to inspect a package’s configure flags, phases, etc. 👇
guix.gnu.org/manual/devel/en/h

13 comments
Csepp 🌢

@civodul I don't quite get why these need to be REPL commands instead of normal functions. 🤔

Ludovic Courtès

@csepp The answer is twofold: (1) providing concise ways to express things packagers may want to do, and (2) presenting data in a human-friendly way (lowering gexps and pretty-printing the result).

One can still do “,pp (package-arguments grep)” but that’s less convenient.

See issues.guix.gnu.org/67489 for a discussion.

Csepp 🌢

@civodul The problem is that this makes hard to use these in scripts. I ran into exactly this issue when I was writing my MirageOS importer (which I promise I'm gonna try upstreaming during the holidays 😅). I needed to build a package that just ran mirage configure and use the dune config file from it to get the dependency list and call the opam importer, which then generated the code.
Sure, I figured out how to do it in the end, but it was more complicated than just calling (build thing).

Csepp 🌢

@civodul Maybe this is a too far reaching problem, but: if the issue is that the string serializations of packages are not nice to read, why not make Guile serialize things nicely by default?
Maybe Scheme should have a separate generic interface/typeclass/whatever for pretty printing and concise serialization, similar to Rust.

Ludovic Courtès

@csepp This is meant as a handy interface to inspect packages.

Doing the same in a script is ~10 lines of code:
git.savannah.gnu.org/cgit/guix

But it’s not so useful: in a script, you’d rather call ‘package-arguments’ and preserve gexps as is instead of lowering them, or you’d lower the whole package.

Janneke

@civodul the ",phases grep" is pretty nice; how would you print grep's phases for --system=i586-gnu?

Ludovic Courtès

@janneke Currently you have to explicitly do (%current-system "i586-gnu") beforehand.

Janneke

@civodul just tried it

$ ./pre-inst-env guix repl
scheme@(guix-user)> ,use(guix)
scheme@(guix-user)> ,use(guix utils)
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> (%current-system "i586-gnu")
$1 = "x86_64-linux"
scheme@(guix-user)> ,make-flags coreutils
scheme@(guix-user)> ,make-flags coreutils
$3 = (list (string-append "XFAIL_TESTS="
" test-fdutimensat"
" test-futimens"
" test-linkat"
" test-renameat"
" test-renameatu"
" test-utimensat"))

-- lovely!

@civodul just tried it

$ ./pre-inst-env guix repl
scheme@(guix-user)> ,use(guix)
scheme@(guix-user)> ,use(guix utils)
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> (%current-system "i586-gnu")
$1 = "x86_64-linux"
scheme@(guix-user)> ,make-flags coreutils
scheme@(guix-user)> ,make-flags coreutils
$3 = (list (string-append "XFAIL_TESTS="
" test-fdutimensat"
" test-futimens"
" test-linkat"
" test-renameat"
" test-renameatu"
" test-utimensat"))

Pjotr Prins

@janneke @civodul Can we compile define-public on the fly? That will be shockingly effective.

Sharlatan

@civodul Why not to include the common Guix's modules to load as an entry point? To reduce the number of representative commands:
```
scheme@(guix-user)> ,use (guix)
scheme@(guix-user)> ,use (gnu packages base)
```

Maybe (guix), (guix utils) and some others.

Ludovic Courtès

@sharlatan There are situations where having ‘guix repl’ load stuff upfront is not desirable (I can’t recall the details off the top of my head).

Go Up