[PATCH] gnu: zuo: Use mirrored repository.

  • Done
  • quality assurance status badge
Details
4 participants
  • Liliana Marie Prikler
  • Ludovic Courtès
  • Maxime Devos
  • Philip McGrath
Owner
unassigned
Submitted by
Liliana Marie Prikler
Severity
normal
L
L
Liliana Marie Prikler wrote on 8 Sep 2022 19:27
(address . guix-patches@gnu.org)
f96c32ff8af7a83e5497e886c383af576f5a79eb.camel@gmail.com
This makes it so that zuo follows our packaging guidelines on version numbers
and gives meaning to the home-page.

* gnu/packages/racket.scm (zuo)[version]: Use git-version.
[source]: Use “https://github.com/racket/zuo”as URL.
Adapt patches accordingly.
[arguments]: Drop phases.
---
gnu/packages/racket.scm | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)

Toggle diff (49 lines)
diff --git a/gnu/packages/racket.scm b/gnu/packages/racket.scm
index 10f93a1362..e3a9360a75 100644
--- a/gnu/packages/racket.scm
+++ b/gnu/packages/racket.scm
@@ -232,28 +232,26 @@ (define %racket-origin
(define-public zuo
- (let ((revision #f))
+ (let ((revision "1")
+ (commit "dcde608b20cf0d71e34300e21cbeeb0509f391a3"))
(package
(name "zuo")
- (version (string-append %zuo-version
- "-racket"
- %racket-version
- (if revision "-guix" "")
- (or revision "")))
- (source %racket-origin)
+ (version (git-version "1.0" revision commit))
+ (source (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/racket/zuo")
+ (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "094jhhi5672qyq7ynrd2fzxc08rrcgs58pzrfn1dyw8rdrfkrdgg"))
+ (patches (search-patches "racket-zuo-bin-sh.patch"))
+ (patch-flags '("-p4"))))
(outputs '("out" "debug"))
(build-system gnu-build-system)
(arguments
- (list
- #:out-of-source? #t
- #:phases
- #~(modify-phases %standard-phases
- (add-after 'unpack 'chdir
- (lambda args
- (chdir "racket/src/zuo"))))))
+ (list #:out-of-source? #t))
(home-page "https://github.com/racket/zuo")
- ;; ^ This is downstream of https://github.com/racket/racket,
- ;; but it's designed to be a friendly landing place
(synopsis "Tiny Racket for build scripts")
(description "Zuo is a tiny Racket with primitives for dealing
with files and running processes. It comes with a @command{make}-like
--
2.37.2
M
M
Maxime Devos wrote on 9 Sep 2022 14:42
762e2739-21b0-a475-9b0b-d7a6f568db88@telenet.be
On 08-09-2022 19:27, Liliana Marie Prikler wrote:
Toggle quote (6 lines)
> This makes it so that zuo follows our packaging guidelines on version numbers
> and gives meaning to the home-page.
>
> * gnu/packages/racket.scm (zuo)[version]: Use git-version.
> [source]: Use “https://github.com/racket/zuo” as URL.
> Adapt patches accordingly.
Why the switch from upstream to a mirror?
For the home-page:
be upstream (and also meaningful).
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
L
L
Liliana Marie Prikler wrote on 9 Sep 2022 14:55
83f1969678354ee3018449cc6c362a49deb1489e.camel@gmail.com
Am Freitag, dem 09.09.2022 um 14:42 +0200 schrieb Maxime Devos:
Toggle quote (14 lines)
> On 08-09-2022 19:27, Liliana Marie Prikler wrote:
> > This makes it so that zuo follows our packaging guidelines on
> > version numbers
> > and gives meaning to the home-page.
> >
> > * gnu/packages/racket.scm (zuo)[version]: Use git-version.
> > [source]: Use “https://github.com/racket/zuo”  as URL.
> > Adapt patches accordingly.
>
> Why the switch from upstream to a mirror?
>
> For the home-page:
> https://github.com/racket/racket/tree/master/racket/src/zuo appears
> to be upstream (and also meaningful).
The mirror is noted as home-page (you have to ask Philip as to why),
but more importantly, it makes versioning easier. Also, it lets us
update zuo independently of racket (see the backport that we no longer
have to apply) and hopefully allows us to unbundle zuo from racket
later.

Cheers
P
P
Philip McGrath wrote on 19 Sep 2022 04:06
a9beb36a-797d-f6c2-587c-09fd0c862a51@philipmcgrath.com
Hi,

I only happened to see this patch just now when looking up a reference
for something else. The guix-patches and bug-guix are too high-volume
for me to follow closely.

On 9/9/22 08:55, Liliana Marie Prikler wrote:
Toggle quote (17 lines)
> Am Freitag, dem 09.09.2022 um 14:42 +0200 schrieb Maxime Devos:
>> On 08-09-2022 19:27, Liliana Marie Prikler wrote:
>>> This makes it so that zuo follows our packaging guidelines on
>>> version numbers
>>> and gives meaning to the home-page.
>>>
>>> * gnu/packages/racket.scm (zuo)[version]: Use git-version.
>>> [source]: Use “https://github.com/racket/zuo”  as URL.
>>> Adapt patches accordingly.
>>
>> Why the switch from upstream to a mirror?
>>
>> For the home-page:
>> https://github.com/racket/racket/tree/master/racket/src/zuo appears
>> to be upstream (and also meaningful).
> The mirror is noted as home-page (you have to ask Philip as to why),

I hadn't heard concern about the home-page until now. If
https://github.com/racket/zuo is a problem I'd prefer
suggested, or even https://docs.racket-lang.org/zuo/, rather than
switching to a mirror.

Toggle quote (2 lines)
> but more importantly, it makes versioning easier.

To me, it seems to make versioning significantly harder. A version
number like 1.0-1.dcde608b doesn't communicate probably the most
important fact about the Zuo version, which is how it relates to the
Racket version. There is no 'v8.6' tag in the mirror repository (which
may just have been an oversight), and commits there don't give the
original commit id (I will suggest that upstream), so you have to
manually match up commit messages in the logs.

If you don't like:

- (version (string-append %zuo-version
- "-racket"
- %racket-version
- (if revision "-guix" "")
- (or revision "")))

I'd be fine with `(git-version %zuo-version revision %racket-commit)`.

Toggle quote (3 lines)
> Also, it lets us
> update zuo independently of racket

I think that would be counterproductive, as I tried at length to explain
in https://issues.guix.gnu.org/57050#46. Racket has a strong
commitment to compatibility for public APIs, but things that are
developed in the main repository are there because they rely on
especially close integration with the core runtime system: there is no
attempt to make arbitrary versions work together. In fact, package
catalogs, snapshots, releases, development builds, and the package
system all have mechanisms to keep the versions in sync. I don't know of
any concrete issues with the C-based Zuo implementation specifically,
but I can say no one is going to put any effort into making Racket's
build scripts work with any version of Zuo other than the one they are
developed with.

Toggle quote (3 lines)
> (see the backport that we no longer
> have to apply)

If you want to avoid "racket-backport-8.6-zuo.patch", I would even
prefer giving 'zuo' an origin that inherits from '%racket-origin' but
uses commit cf82706c4b298f654a04c4bc8d98dff39b62a2ac rather than
switching to the mirror repository.

I think it's even better to have a consistent source tree for the main
Racket repository, but at least keeping the repository in the right
shape would keep --with-git-url/--with-commit working. The mirror
repository is not useful for development.

Toggle quote (4 lines)
> and hopefully allows us to unbundle zuo from racket
> later.
>

Either I don't understand what you have in mind or I just disagree that
it's desirable.

When I hear the word "unbundle", I think of configuring Racket and Chez
Scheme to use our shared Zlib and removing their vendored copies. I
don't see how the concept applies usefully to the scenario of multiple
pieces of software, some of which are useful independently, being
developed upstream in the same source tree. Like, what would it mean to
"unbundle" gfortran from gcc?

-Philip
M
M
Maxime Devos wrote on 19 Sep 2022 15:53
42f7a392-4716-eba7-d237-0241b3f8fada@telenet.be
Toggle quote (1 lines)
The documentation sounds better as a home page to me than a link to the
source code.
On 19-09-2022 04:06, Philip McGrath wrote:
Toggle quote (6 lines)
> When I hear the word "unbundle", I think of configuring Racket and Chez
> Scheme to use our shared Zlib and removing their vendored copies. I
> don't see how the concept applies usefully to the scenario of multiple
> pieces of software, some of which are useful independently, being
> developed upstream in the same source tree. Like, what would it mean to
> "unbundle" gfortran from gcc?
In case of gcc, I think updating the components separately doesn't make
much sense (from what I hear, it's the same situation for Racket and
Zuo, where 'Zuo' is just a component of Racket, not something
independent that's 'merely' a dependency of Racket).
However, for gcc, _building_ the components in separately does IMHO --
many users don't need GCC's Go or Fortran compiler, so they are separate
packages. However, IIUC, currently when building gccgo and gfortran it
also rebuilds the internal dependencies like libiberty and libgcc and
such, which is inefficient, so I think it would be nice to eventually
split the gcc package in its individual component (but sharing a single
origin!).
(I don't know if the second paragraph applies to Racket and Zuo.)
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
L
L
Liliana Marie Prikler wrote on 19 Sep 2022 20:33
81143ee5f3b8f26c5f9b9dbae525b20b1d8a6ec9.camel@gmail.com
Am Montag, dem 19.09.2022 um 15:53 +0200 schrieb Maxime Devos:
Toggle quote (12 lines)
> On 19-09-2022 04:06, Philip McGrath wrote:
> > When I hear the word "unbundle", I think of configuring Racket and
> > Chez Scheme to use our shared Zlib and removing their vendored
> > copies. I don't see how the concept applies usefully to the
> > scenario of multiple pieces of software, some of which are useful
> > independently, being developed upstream in the same source tree.
> > Like, what would it mean to "unbundle" gfortran from gcc?
>
> In case of gcc, I think updating the components separately doesn't
> make much sense (from what I hear, it's the same situation for Racket
> and Zuo, where 'Zuo' is just a component of Racket, not something
> independent that's 'merely' a dependency of Racket).
I'd like to point out that the purpose of Zuo is basically having a
schemey make. We don't bundle make with GCC, do we?

Am Sonntag, dem 18.09.2022 um 22:06 -0400 schrieb Philip McGrath:
Toggle quote (4 lines)
> To me, it seems to make versioning significantly harder. A version
> number like 1.0-1.dcde608b doesn't communicate probably the most
> important fact about the Zuo version, which is how it relates to the
> Racket version.
That's exactly the point, though; there's no reason it has to. As long
as Racket builds with Zuo, I don't see a reason to communicate this
information.

Toggle quote (4 lines)
> There is no 'v8.6' tag in the mirror repository (which may just have
> been an oversight), and commits there don't give the original commit
> id (I will suggest that upstream), so you have to manually match up
> commit messages in the logs.
Separate packages can have separate versioning schemes. As far as I'm
aware, Zuo is starting a fresh counting round, so it doesn't make too
much sense to link its versioning to Racket (particularly if as you
point out it has uses besides bootstrapping Racket).

As for matching up commits when updating, I'm pretty sure this part of
the process could be automated if you feel particularly lazy, but even
if not, a properly configured git forge ought to give you the commit
hash by searching part of its message (on the zuo end) and also allow
you to see the last commit that modified a subtree (on the racket end).

Cheers
M
M
Maxime Devos wrote on 19 Sep 2022 20:40
6dc2efa9-7c63-609c-2346-9a7df84518ed@telenet.be
On 19-09-2022 20:33, Liliana Marie Prikler wrote:
Toggle quote (14 lines)
> Am Montag, dem 19.09.2022 um 15:53 +0200 schrieb Maxime Devos:
>> On 19-09-2022 04:06, Philip McGrath wrote:
>>> When I hear the word "unbundle", I think of configuring Racket and
>>> Chez Scheme to use our shared Zlib and removing their vendored
>>> copies. I don't see how the concept applies usefully to the
>>> scenario of multiple pieces of software, some of which are useful
>>> independently, being developed upstream in the same source tree.
>>> Like, what would it mean to "unbundle" gfortran from gcc?
>> In case of gcc, I think updating the components separately doesn't
>> make much sense (from what I hear, it's the same situation for Racket
>> and Zuo, where 'Zuo' is just a component of Racket, not something
>> independent that's 'merely' a dependency of Racket).
> I'd like to point out that the purpose of Zuo is basically having a
> schemey make. We don't bundle make with GCC, do we?
We don't, and it don't see how this comparison is relevant -- how is
being make-ish relevant to whether something is bundling or whether
something is acceptable to bundle?
Unlike Zuo only being used as part of Racket and developed as part of
Racket (to my knowledge), "make" is used and developed outside GCC, with
an independent release cycle.
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
L
L
Ludovic Courtès wrote on 7 Nov 2022 22:22
control message for bug #57683
(address . control@debbugs.gnu.org)
87v8nqsbmj.fsf@gnu.org
tags 57683 wontfix
close 57683
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 57683@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 57683
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch