Hi,

On Saturday, February 26, 2022 11:14:38 AM EST Liliana Marie Prikler wrote:
> Hi,
> 
> Am Samstag, dem 26.02.2022 um 10:36 -0500 schrieb Philip McGrath:
> > Hi,
> > 
> > On Saturday, February 26, 2022 10:08:30 AM EST Liliana Marie Prikler
> > 
> > wrote:
> > > Am Samstag, dem 26.02.2022 um 08:02 -0500 schrieb Philip McGrath:
> > > > I realized that, if we just pass the origin some other way than
> > > > as the 'source' field, we can avoid adding the
> > > > "chez-and-racket-bootstrap.scm" file
> > > > altogether: patch v5 10/22 does the core of that.
> > > 
> > > I did miss that nugget when I skimmed it first; is there a reason
> > > to prefer overloading unpack and redirecting it to (package-source
> > > racket-vm-bc) over doing the same, but using simply #$%racket-
> > > origin?
> > 
> > I like this:
> > > > +            (replace 'unpack
> > > > +              (lambda args
> > > > +                (unpack #:source #$(or (package-source this-
> > > > package)
> > > > +                                       (package-source racket-
> > > > vm-bc)))))
> > 
> > rather than:
> > 
> >     (unpack #:source #$(package-source racket-vm-bc))
> > 
> > to make it easier for a user to provide an alternate source.
> 
> Hmm, to be fair this would probably respect --with-source, which I was
> missing, but I'm not sure how deep into the bootstrap we could inject
> this.  Sadly, we can't make chez-scheme-for-racket itself a
> transformation.
> 
> > My concern with:
> > 
> >     (unpack #:source #$(or (package-source this-package) %racket-
> > origin))
> > 
> > is less strong, but if `(gnu packages racket)` exports `%racket-
> > origin`, it
> > seems like it would be very tempting to put it in a `source` field,
> > but of course that would cause problems. My hope was that having to
> > write `(package-source racket-vm-bc)` might prompt a little more
> > thought.
> 
> Hmm.  And what if we go my earlier route of defining this as a
> procedure in chez and instantiating it inside racket.scm?  We should
> not get a cycle triggered by chez-scheme-for-system if we do, but we
> might get one if we attempt to bind it to a variable in racket.scm.
> 
> That aside, there is also the possibility of using a gexp promise as
> source, as is done for example in the case of linux-libre.  If we wrap
> the chez side in a promise, that ought to resolve the cycle as well.
> 

Interesting ... I'll have to take a look at that.

In the medium term, for Racket packages, I think the 'racket-build-system' 
ought to provide some support for using a different Racket. For Chez Scheme 
packages it's probably less complicated. (At least, I've had no problems with 
the things I've tried.)

For now, mostly I thought it would be very surprising if `unpack` silently 
ignored the package's `source` and unpacked something else, instead.

> > > BTW for the record, if you're dropping one of my mails from the
> > > CCs, please make sure to include the gmail account rather than my
> > > institute mail.  This one is technically supposed to be for work
> > > and I'm using a rather loose interpretation of "ensuring that
> > > software is up-to-date" as part of my work when I do comment on
> > > Guix issues from it.
> > 
> > Will do, sorry! (I've been experimenting with MUAs recently and not
> > getting everything right—you may have noticed I sent mail earlier
> > from an address I wasn't intending to use.)
> 
> I haven't noticed, but thanks for pointing this out.  If a commit from
> the wrong address does make it into our git history, please do point
> that out; I'll be happy to adjust the mailmap for you.
> 

Thankfully git and git-send-email have been fine; only a couple prose messages 
came from the wrong address.

-Philip