guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. Bootstrap from C.


From: Ludovic Courtès
Subject: [bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. Bootstrap from C.
Date: Thu, 08 Jul 2021 23:25:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi!

Philip McGrath <philip@philipmcgrath.com> skribis:

> * gnu/packages/racket.scm (racket-next-minimal,racket-next): New variables.

[...]

> +++ b/gnu/packages/racket.scm
> @@ -23,6 +23,7 @@
>    #:use-module ((guix licenses)
>                  #:select (asl2.0 expat lgpl3+))
>    #:use-module (guix packages)
> +  #:use-module (guix base16)

Leftover?

> +;; Preliminary guidelines on naming things:
> +;;   - `racket` is the main package. It corresponds to `racket-minimal`
> +;;     with the Racket-level package "main-distribution" installed.
> +;;   - `racket-minimal` is Racket runtime system and core libraries:
> +;;     just enough to implement the package system and install the rest.
> +;;     Upstream refers to this as "minimal Racket".

Note that these two names match existing conventions in Guix.

I’d suggest moving the bits about the package contents/features next to
the definition of ‘racket’ and ‘racket-minimal’.

> +;;   - `racket-pkg-` should probably be the prefix for Racket packages
> +;;     available as Guix packages, once we're able to build those.
> +;;     More specifically, it should correspond
> +;;     to packages registered in the catalog at https://pkgs.rackat-lang.org.
> +;;     This is a social convention to manage the namespace, not a technical
> +;;     limitation: Racket can use other catalogs (e.g. for pre-built packages
> +;;     or packages pinned to specific versions), unregistered package source
> +;;     urls, or purely local packages. But we also need a convention to
> +;;     manage the namespace, so we should use this one. In practice,
> +;;     all generally useful libre Racket packages are registered there.
> +;;     We probably will need a clever encoding scheme to deal with the fact
> +;;     that Racket package names can contain [A-Za-z_-], i.e. including "_",
> +;;     which is not allowed in Guix package names.

For this there’s already a documented convention (info "(guix) Package
Naming"), although part of it is undocumented.  The prefix would rather
be “racket-” to match what we do with other packages–“ghc-”, “ocaml-”,
“guile-”, and so forth.

> +;;   - `racket-next` is a development version of `racket`, following either
> +;;     the upstrean Git HEAD or the release candidate, when one exists.
> +;;   - `racket-next-` is the prefix for other development packages,
> +;;     including `racket-next-minimal`. When we can build Racket packages
> +;;     individually, we will need `racket-next-pkg-` for the packages
> +;;     that make up `racket-next`.

These two are also conventional and don’t need to be documented here
IMO.

> +(define %pre-release-installers
> +  "https://pre-release.racket-lang.org/installers/";)
> +
> +(define-public racket-next-minimal
> +  (package
> +    (inherit racket-minimal)
> +    (name "racket-next-minimal")
> +    (version "8.1.900")
> +    (source
> +     (origin
> +       (inherit (package-source racket-minimal))
> +       (sha256
> +        (base32
> +         "0dm849wvlaxpfgz2qmgy2kwdslyi515rxn1m1yff38lagbn21vxq"))
> +       (uri (string-append %pre-release-installers
> +                           "racket-minimal-src.tgz"))))))
> +
> +(define-public racket-next
> +  (package
> +    (inherit racket)
> +    (name "racket-next")
> +    (version (package-version racket-next-minimal))
> +    (source
> +     (origin
> +       (inherit (package-source racket))
> +       (sha256
> +        (base32
> +         "0ysvzgm0lx4b1p4k9balvcbvh2kapbfx91c9ls80ba062cd8y5qv"))
> +       (uri (string-append %pre-release-installers
> +                           "racket-src.tgz"))))))

Do I get it right that *-src.tgz are not versioned?  That they’re
updated in place regularly?

In that case, we cannot refer to them in a package definition since the
hash is bound to become stale.

What we could do is refer to, say,
<https://pre-release.racket-lang.org/installers/racket-8.1.900.1-src.tgz>.
However, I suspect this file would vanish fairly quickly from the web
site, which is not okay either.

I’m not sure what a good solution would be.  WDYT?

It may be that
‘--with-source=https://pre-release.racket-lang.org/installers/racket-src.tgz’
would do the job for those who’re into that.

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]