[bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2.

[Leo Prikler]

Am Montag, den 19.07.2021, 17:46 -0400 schrieb Philip McGrath:
> Hi,
> 
> On 7/19/21 3:46 PM, Leo Prikler wrote:
> > Am Montag, den 19.07.2021, 02:31 -0400 schrieb Philip McGrath:
> > > * gnu/packages/racket.scm (racket-minimal, racket): Update to
> > > 8.2.
> > > * gnu/packages/racket.scm (racket-minimal)[#:arguments]: Fix
> > > patch-config.rktd-lib-search-dirs phase. When a config.rktd file
> > > doesn't contain an entry for `lib-search-dirs`, the default is
> > > equivalent to `'(#f)`, not `'()`.
> > What is the point of this value?  Can we use a (sequence of)
> > string(s)
> > in its stead?
> 
> As you'd probably guess, `lib-search-dirs` and other `-search-dirs` 
> "config.rktd" entries specify search paths. The `#f` value is used
> to 
> specify the point at which the default search path should be spliced 
> into the list: a configuration file can ignore the default altogether
> or 
> exercise fine-grained control over the search order. Using `#f` also 
> helps to maintain something closer to a single point of control,
> rather 
> than hard-code the same string constants in several places.
Okay, but for this specific config, we could still splice #f ourselves
(particularly to also get full store paths), or can we not thanks to
the non-constant nature of #f?

> Most importantly, the default value is not always a constant: for 
> example, command-line flags and Racket parameters control whether 
> user-specific paths are included.
How exactly would this play out?  Would for example one version of #f
contain all of the user-installed packages in ~/.guix-profile whereas
the other would only contain racket's own path?

> (For `lib-search-dirs` in particular, it's also worth noting that
> these are Racket-specific search directories: it does not control the
> use of OS-level defaults for e.g. `dlopen`.)
Perhaps a confusing naming scheme, but okay.

> The problems with omitting `#f` from `lib-search-dirs` were not very 
> noticeable until the patch to start using layered and tethered 
> installations. For a more obvious example, if `catalogs` is `'()`,
> `raco pkg` won't consult any package catalogs, whereas `'(#f)` will
> cause it to use the default catalogs.
Okay, but `catalogs` is not `lib-search-dirs`, is it?  I'd assume
`'(#f)` is roughly equivalent to `'("default")` or `'("@spam@" "@ham@"
"@eggs@")` for some configure-time constant spam, ham and eggs.  Or
does the command-line flag variability apply to catalogs as well?

> The documentation for these configuration options is here: 
> https://docs.racket-lang.org/raco/config-file.html#(idx._(gentag._70._(lib._scribblings%2Fraco%2Fraco..scrbl)))
> 
> (As of this writing, the docs on the website are still at 8.1---the 
> whole package catalog is rebuilt after a new Racket release, which
> takes a little while to finish. You could alternatively apply this
> patch and run `lynx "file://"$(./pre-inst-env guix build 
> racket)"/share/doc/racket/raco/config-
> file.html#(idx._(gentag._70._(lib._scribblings%2Fraco%2Fraco..scrbl))
> )"`.)
I think more important than the semantics of the configuration file is
the purpose of this particular thing.  Is it a template from which
other stuff is derived?  In that case, we might want to use #f as you
did.  Is it instead used to build stuff in the racket package?  Then
we'd need to substitute it imo.

Regards