Message ID | f96c32ff8af7a83e5497e886c383af576f5a79eb.camel@gmail.com |
---|---|
State | New |
Headers | show |
Series | [bug#57683] gnu: zuo: Use mirrored repository. | expand |
Context | Check | Description |
---|---|---|
cbaines/comparison | success | View comparision |
cbaines/git-branch | success | View Git branch |
cbaines/applying patch | success | View Laminar job |
cbaines/issue | success | View issue |
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.
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
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
> 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.
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
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.
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