Ludovic Courtès <[email protected]> writes:
Hi Jason,
Jason Conroy <[email protected]> skribis:
So I'd like to know: what are the best practices for these two
related
features? Unfortunately I wasn't able to find much info in the
manual.
Private packages (using ‘define’ instead of ‘define-public’)
should
rather be avoided because they are invisible to ‘fold-packages’,
which
then causes Cuirass to behave poorly:
https://codeberg.org/guix/guix/pulls/6781
Ok, thanks. Judging from an error log in #5966 [1], I guess this
happens when Cuirass resolves a public package and one of its
dependencies is private?
Then the question becomes when to mark a package as hidden.
This is
still unwritten knowledge, but existing practice is along these
lines:
https://codeberg.org/guix/guix/pulls/5996#issuecomment-10828109
I wonder if folks have thoughts on the following use case, which
is also "for internal consumption only", but not in a sense that
involves the package graph.
For defining a set of related packages, I have seen the following
pattern:
;; Private "base package"
(define %foobar-base
(package
(name "foobar-base")
(source ...)
(build-system ...)
...))
(define-public foobar-libs
(package
(inherit %foobar-base)
(name "foobar-libs")
...))
(define-public foobar-bin
(package
(inherit %foobar-base)
(name "foobar-bin")
...))
... etc. A more common solution is to skip the base package and
define foobar-bin in terms of foobar-libs directly, but this is
error-prone: record fields intended for sharing between packages
are too easily confused with "private" record fields.
I can imagine other ways to approach the problem, but they either
involve more boilerplate or some sort of macro.
Any thoughts on the most elegant idiom?
Cheers,
Jason
[1]
https://codeberg.org/guix/guix/pulls/5996#issuecomment-10240316
