[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Liliana Marie Prikler]

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(-)

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

[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 533 bytes --]



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).

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Liliana Marie Prikler]

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),
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

[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Philip McGrath]

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:
> 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 
<https://github.com/racket/racket/tree/master/racket/src/zuo>, as Maxime 
suggested, or even <https://docs.racket-lang.org/zuo/>, rather than 
switching to a mirror.

> 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)`.

> 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.

> (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.

> 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

[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1386 bytes --]

 > https://docs.racket-lang.org/zuo/

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:
> 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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Liliana Marie Prikler]

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?

Am Sonntag, dem 18.09.2022 um 22:06 -0400 schrieb Philip McGrath:
> 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.

> 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

[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 1358 bytes --]



On 19-09-2022 20:33, Liliana Marie Prikler wrote:
> 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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]