bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Philip McGrath <philip@philipmcgrath.com> skribis:

> On 5/29/21 4:15 PM, Ludovic Courtès wrote:
>> In general we cannot use #:select for (gnu packages …) modules because
>> that doesn’t play well with circular module dependencies.
>
> Ah, interesting, I'll keep that in mind. I'm used to Racket, where all
> cyclic module dependencies cause errors at compile time.

Yeah, in hindsight, that’s probably safer…

> Do you have any advice on what would be good practice?

For package modules, the main things are:

  1. Don’t use #:select or #:autoload for (gnu packages …) modules in a
     (gnu packages …) module.

  2. At the top level of a module, only refer to variables within that
     module.  For instance, the following would be wrong:

       (define-module (gnu packages racket)
         #:use-module (gnu packages chez)
         …)

       (define whatever
         ;; Wrong because ‘chez-scheme’ is defined in another module,
         ;; which might be part of a cycle with this one.
         (package (inherit chez-scheme) …))

       (define something
         (package
           ;; …
           (license (package-license chez-scheme))))  ;likewise

Note that references from ‘inputs’ and ‘arguments’ fields are perfectly
fine (fortunately!) because those fields are “thunked” (their value is
wrapped in a thunk).

> In the near future, I'll want to get the `nanopass` and `stex` origins
> for Racket, potentially via `(package-inputs
> chez-scheme)`---especially because those are not exported
> variables. And also this part:
>
>>    - The `chez-scheme` phases `unpack-nanopass+stex`, `configure`,
>>      `prepare-stex`, and `install-doc` should be shared with Racket.
>>      I think it would be better to put them in a build-side module and
>>      actually share them, rather than to do tricky things to extract
>>      their s-expression representation from
>>      `(package-arguments chez-scheme)`. On the other hand, I think a
>>      build system would be overkill: it would only build vanilla Chez
>>      and Racket-flavored Chez.
>
> I'm getting very close to being able to make `racket` accept
> `racket-minimal` as an input, rather than duplicate most of it. This
> is exercising some features Racket has theoretically had for a while,
> but which apparently didn't quite work until ... well, this afternoon
> it worked for me outside of Guix, thanks to a bunch of fixes in the
> last few weeks by Matthew Flatt.

Neat.

> Would it make sense for me, when some useful amount of this works, to
> send a patch series adding a `racket-next` package? I think the
> changes are too much to backport to Racket 8.1.

Possibly, your call!  :-)

Thanks,
Ludo’.