Using (recursive #t) in (origin git-reference)

Using (recursive #t) in (origin git-reference)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi,

Is there a trick to fetching Git submodules with (recursive? #t)? It
does not seem to work with the package definition below.

The code uses Ekaitz's proposed Zig build system. [1] Thank you!

Kind regards
Felix

[1] https://issues.guix.gnu.org/60889

* * *
gnu: Add river.

* gnu/packages/zig.scm (river): New variable.

1 file changed, 45 insertions(+), 2 deletions(-)
gnu/packages/zig-xyz.scm | 47 +++++++++++++++++++++++++++++++++++++++++++++--

modified   gnu/packages/zig-xyz.scm
@@ -21,10 +22,52 @@ (define-module (gnu packages zig-xyz)
   #:use-module (guix git-download)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system zig)
   #:use-module (guix gexp)
   #:use-module (gnu packages)
-  #:use-module (gnu packages zig)
-  #:use-module (gnu packages python))
+  #:use-module (gnu packages freedesktop)
+  #:use-module (gnu packages man)
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages python)
+  #:use-module (gnu packages wm)
+  #:use-module (gnu packages xdisorg)
+  #:use-module (gnu packages xorg)
+  #:use-module (gnu packages zig))
+
+(define-public river
+  (package
+    (name "river")
+    (version "0.2.4")
+    (source (origin
+              (method git-fetch)
+              (uri (git-reference
+                    (url "https://github.com/riverwm/river")
+                    (commit (string-append "v" version))
+                    (recursive? #t)))
+              (file-name (git-file-name name version))
+              (sha256
+               (base32
+                "1kh5yh2a47vr2q9paivmm3d57rcbb3f2p6d4f4r4k6f7jf62391n"))))
+    (build-system zig-build-system)
+    (arguments
+     (list
+      #:zig-build-flags #~(list "-Dxwayland")  ;experimental xwayland support
+      #:zig-release-type "safe"))
+    (native-inputs (list
+                    libevdev
+                    libxkbcommon
+                    pkg-config
+                    pixman
+                    scdoc
+                    wayland
+                    wayland-protocols
+                    wlroots))
+    (home-page "https://github.com/riverwm/river")
+    (synopsis "Dynamic tiling Wayland compositor")
+    (description "River is a dynamic tiling Wayland compositor with flexible
+runtime configuration.  It can run nested in an X11/Wayland session or also
+directly from a tty using KMS/DRM.")
+    (license license:gpl3)))

 (define-public zig-zls
   (package

Re: Using (recursive #t) in (origin git-reference)

[(]

Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> writes:
> Is there a trick to fetching Git submodules with (recursive? #t)? It
> does not seem to work with the package definition below.
>
> The code uses Ekaitz's proposed Zig build system. [1] Thank you!

Not sure whether or not you've already done this, but when you're doing
``(recursive? #t)'' the hash will be for the source code with submodules
checked out, so you need to fetch them all in your ``git clone'' before
doing ``guix hash -rx .''.

(If you've already tried building it without the RECURSIVE?, then this
issue will go unnoticed, as the derivation paths for these two objects:

  (origin
    (method git-fetch)
    (uri (git-reference
          (url "…")
          (commit (string-append "v" version))))
    …)

  (origin
    (method git-fetch)
    (uri (git-reference
          (url "…")
          (commit (string-append "v" version))
          (recursive? #t)))
    …)

are *exactly the same*, as the output path is the hash, followed by a
dash, followed by whatever's given in FILE-NAME.  Thus, they are treated
as exactly the same object, making rebuilding pointless in Guix's eyes,
because you've already got that "same" output in your store from the
first build without RECURSIVE?.

This is also, funnily enough, why it's not a great idea to first copy
another origin's hash, then try to build, in the hopes of getting the
actual hash from the "expected hash: …" message; if you haven't changed
the FILE-NAME, or haven't included one, the output path will be exactly
the same as the original package's, meaning that one will be used as the
source if you happen to have it in your store! [IIUC, of course.])

That being said, you may know all this and have already taken it into
account, in which case I'm not sure what's going on here :)

  -- (

Re: Using (recursive #t) in (origin git-reference)

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi unmatched-paren!

On Tue, Jun 20, 2023 at 11:52 AM ( <paren@disroot.org> wrote:
>
> (If you've already tried building it without the RECURSIVE?, then this
> issue will go unnoticed, as the derivation paths [...]
> are *exactly the same*

Okay, that nipped me in the hiney. Now it works!

Thanks for explaining! You are an invaluable as well as instant
resource for this list.

Kind regards
Felix

Re: Using (recursive #t) in (origin git-reference)

[John Kehayias]

On Tue, Jun 20, 2023 at 12:33 PM, Felix Lechner via \"Development of GNU Guix and the GNU System distribution.\" wrote:

> Hi unmatched-paren!
>
> On Tue, Jun 20, 2023 at 11:52 AM ( <paren@disroot.org> wrote:
>>
>> (If you've already tried building it without the RECURSIVE?, then this
>> issue will go unnoticed, as the derivation paths [...]
>> are *exactly the same*
>
> Okay, that nipped me in the hiney. Now it works!
>
> Thanks for explaining! You are an invaluable as well as instant
> resource for this list.
>

Yes, thanks for the quick response (!

This happens enough I feel like it should be explicitly mentioned as a potential "gotcha" in the manual, even if one can gleam it from understanding package definitions and hashes, if it isn't already. Or maybe a little "tips" section on packaging (or in the cookbook) with something like this and related ones like idiosyncrasies/conventions in certain language ecosystems. We all accumulate a lot of institutional knowledge as we do and pass it along, but better to have it properly referenced.

John

Re: Using (recursive #t) in (origin git-reference)

[(]

John Kehayias <john.kehayias@protonmail.com> writes:
> This happens enough I feel like it should be explicitly mentioned as a potential
> "gotcha" in the manual, even if one can gleam it from understanding package
> definitions and hashes, if it isn't already. Or maybe a little "tips" section on
> packaging (or in the cookbook) with something like this and related ones like
> idiosyncrasies/conventions in certain language ecosystems. We all accumulate a
> lot of institutional knowledge as we do and pass it along, but better to have it
> properly referenced.

Sounds like an idea.  I definitely think it should go in the manual,
though, as it'll be far more visible there.  (I, personally, have never
read the cookbook in all that much detail...)

  -- (