From: "Ludovic Courtès" <ludo@gnu.org>
To: Philip McGrath <philip@philipmcgrath.com>
Cc: 48682-done@debbugs.gnu.org
Subject: bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)
Date: Mon, 31 May 2021 18:23:27 +0200 [thread overview]
Message-ID: <87lf7u3m9s.fsf@gnu.org> (raw)
In-Reply-To: <fbd68cec-5ff6-0fac-28a7-03b532147065@philipmcgrath.com> (Philip McGrath's message of "Sat, 29 May 2021 18:02:42 -0400")
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’.
prev parent reply other threads:[~2021-05-31 16:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 18:54 bug#48682: recursive import between (gnu packages chez) and (gnu packages racket) raingloom
2021-05-27 4:26 ` Philip McGrath
2021-05-28 2:02 ` raingloom
2021-05-28 18:19 ` Philip McGrath
2021-05-29 20:15 ` Ludovic Courtès
2021-05-29 21:42 ` Philip McGrath
2021-05-29 22:02 ` Philip McGrath
2021-05-31 16:23 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lf7u3m9s.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=48682-done@debbugs.gnu.org \
--cc=philip@philipmcgrath.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.