On Sunday, February 20, 2022 5:16:04 AM EST Liliana Marie Prikler wrote:
> >    #:use-module (gnu packages xorg)
> >    #:use-module ((guix licenses)
> >                  #:prefix license:)
> 
> Small note, #:prefix license: should be on the same line as #:use-
> module.
> 

Ok.

> > -(define %racket-version "8.4")
> > +(define %racket-version "8.4") ; MUST match "racket.scm"
> > +;; The definition of %racket-version is duplicated to avoid an
> > import cycle:
> > +;; see <https://issues.guix.gnu.org/53878#93>.
> >  (define %chez-scheme-for-racket-version "9.5.7.3")
> > [...]
> > +(define %racket-version "8.4") ; MUST match "chez-and-racket-
> > bootstrap.scm"
> > +;; The definition of %racket-version is duplicated to avoid an
> > import cycle:
> > +;; see <https://issues.guix.gnu.org/53878#93>.
> > +(define %racket-commit
> > +  (string-append "v" %racket-version))
> 
> That works, but it's not really nice.  I did send my mail w.r.t. making
> the bootstrap packages procedures that take racket-version and origin
> as arguments before reading this mail, but I think my comment still
> applies mostly.  WDYT?
> 

As I said, I think that would cause an import cycle. This seems like a very 
subtle and confusing issue! I haven't heard anyone but Ludo’ express much 
confidence in their understanding of how this works—certainly I don't feel 
much!

> > +(define (extract-package-source origin spec)
> > +  "Extract the source for a Racket package specified by SPEC from
> > ORIGIN into
> > +a new file-like object.  In the resulting file-like object, the
> > package source
> > +will be in the directory \"/share/racket/pkgs/NAME/\", where NAME is
> > the Racket
> > +name for the package.
> > +
> > +SPEC is a list of the form:
> > +
> > +  (NAME PATH)
> > +
> > +where PATH is the path to the package source relative to ORIGIN---
> > possibly
> > +`\".\"`.  As a special case, SPEC may also be given a string, which
> > is
> > +equivalent to:
> > +
> > +  (NAME NAME)
> > +
> 
> > +Examples:
> Would it make sense to use this procedure for our bootstrap packages
> already?  (In particular for bootfiles or extracting chez-scheme from
> the racket source).
> 

Well, for one thing, trying to use this package in "chez-and-racket-
bootstrap.scm" seems like it could get us into trouble with import cycles 
again. I think it will be less painful if we can have at least "chez-and-
racket-bootstrap.scm", "chez.scm", and "racket.scm" form a DAG.

Also, this function was really intended to handle the quite common
`?path=‹path›` case for Racket Git "package sources"[1]. Eventually, it should 
be part of a `racket-build-system`.

> 
> Regarding the big racket package, the recipe currently looks a little
> nicer in that it no longer overrides `build', but I think we could
> still do a union-build with #:symlink copy-recursively if the full
> racket is just racket plus a bunch of packages on top.  This would have
> the benefit that we could declare each of them as a package.  Not sure
> if this is something we ought to address here or in a separate patch
> set, though.

Well, I certainly do want to declare each of them as a package! But I don't 
know what the benefit would be for doing so before its possible for a Guix user 
to usefully, say, install one.

Maybe you know this, but installing a Racket package isn't just a matter of 
putting a directory in the right place and setting a search path. Most 
obviously, it has to be compiled, and it would be most useful to explicitly 
generate "built packages"[2] separately from installing them into a layer. 
Installation into a layer potentially involves generating collection links 
files, indexing documentation cross-reference information, moving man pages or 
other kinds of files, creating launchers like the `drracket` command, and 
potentially various other steps: indeed, collections (not just packages) can 
specify arbitrary functions to be invoked by `raco setup` at pre-install, 
install, or post-install time. Creating a "config-tethered" layer—the kind we'd 
want to install into a Guix profile, as opposed to a sparse intermediate layer—
also creates new `racket` and other executables in the layer's "bin" directory 
that exec the `racket` from the VM layer while propagating information about 
the layers that have been installed.

Anyway, the packaging for racket@8.4 should be less of a hack than before 
(which was better than when we used to duplicate racket-minimal, VM and all), 
but this is all still fundamentally a hack, and I'd rather spend my effort 
trying to do the right thing, rather than overly fine-tuning the details of the 
temporary workarounds.

-Philip

[1]: https://docs.racket-lang.org/pkg/
Package_Concepts.html#%28part._concept~3asource%29
[2]: https://docs.racket-lang.org/pkg/strip.html