all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: "Ludovic Courtès" <ludovic.courtes@inria.fr>,
	"Björn Höfling" <bjoern.hoefling@bjoernhoefling.de>,
	guix-devel@gnu.org, "Lars-Dominik Braun" <lars@6xq.net>
Subject: Re: Adding content-addressed URLs to https://guix.gnu.org/sources.json
Date: Fri, 28 Apr 2023 15:39:46 +0200	[thread overview]
Message-ID: <87v8hg9lct.fsf@gmail.com> (raw)
In-Reply-To: <87354oqdal.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5203 bytes --]

Hi Ludo, Maxim, all,

On mar., 25 avril 2023 at 14:40, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:

>> Somehow, it reveals 3 currently uncovered cases: computed-file appearing
>> as,
>>
>>  1. ’origin’ in source field (ruby-sorbet-runtime)
>>  2. ’inputs’ (racket-minimal)
>>  3. ’snippet’ in origin in source field (chromium)
>
> I think #1 and #2 are okay: we can use any file-like object there, not
> just origin/package.  Of course, <origin> is meant to be the best choice
> for ‘source’, and <package> the best choice for ‘inputs’.  But I think
> it’s fine to occasionally resort to some other abstraction when these
> two are not adequate.

I agree that any file-like object is nice.  Somehow, the issue is to
“unpack“ the information of this object.  For instance,

--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> (define ruby-sorbet-runtime (@@ (gnu packages ruby) ruby-sorbet-runtime))
scheme@(guix-user)> (package-source ruby-sorbet-runtime)
$1 = #<<computed-file> name: "ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout" gexp: #<gexp (begin (use-modules (guix build utils)) (copy-recursively (string-append #<gexp-input #<origin #<<git-reference> url: "https://github.com/sorbet/sorbet" commit: "0.5.10610.20230106174520-1fa668010" recursive?: #f> #<content-hash sha256:0f21dl06alxwn6xgdxyrkd58plmmsv04z2bcls9ld4cfzsrs5537> () 7fd7ad6b81e0>:out> "/gems/sorbet-" #<gexp-input "runtime":out>) #<gexp-output out>)) gnu/packages/ruby.scm:14071:5 7fd7ae734480> guile: #f options: (#:local-build? #t)>
--8<---------------cut here---------------end--------------->8---

and as far as I understand, this case cannot be handled by some generic
code.  The extraction of the “real” origin needs manual and specific
extraction because of this ’computed-file’.

For sure, ’source’ can use any file-like object because some use-cases
require that.  However, I would be tempted to use an ’origin’ as a
preferred choice – i.e., when it’s possible and try to make it
possible. ;-) Because, somehow, it “normalizes“ the source information
and eases its extraction.


On mar., 25 avril 2023 at 09:52, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> This pattern appears to me wrong.  It should use ’snippet’.  And if the
>> point is to have a meaningful path in /gnu/store, as it is the case with
>> icecat or linux or emacs-company-box, the current way is
>> ’computed-origin-method’ from (guix packages).
>>
>> For ’ruby-sorbet-runtime’, the fix seems ’computed-origin-method’.
>
> Per the source, IIRC, 'computed-origin-method' is also considered a hack
> or workaround around the fact that a snippet can't affect the name of a
> source.  But it's a well established one.  That was indeed the rationale
> here (to have meaningful top level directory names matching the source),
> which is worth it in my opinion.

I agree that ’computed-origin-method’ had been considered as a hack.  I
guess, mainly because at the time, the need seemed singular and that
’snippet’ were maybe less powerful.  For what my opinion is worth,
instead of,

--8<---------------cut here---------------start------------->8---
(define (make-sorbet-gem-source gem)
  "Return the source of GEM, a sub-directory."
  (computed-file
   (string-append "ruby-sorbet-" gem "-" sorbet-version "-checkout")
   (with-imported-modules (source-module-closure '((guix build utils)))
     #~(begin
         (use-modules (guix build utils))
         (copy-recursively (string-append #$sorbet-monorepo
                                          "/gems/sorbet-" #$gem)
                           #$output)))))

(define-public ruby-sorbet-runtime
[...]
    (source (make-sorbet-gem-source "runtime"))
--8<---------------cut here---------------end--------------->8---

I would try to “normalize” this behaviour.  Well, it’s not clear for me
if ’computed-origin-method’ is suitable as a basis for that; somehow it
would appear to me the direction for these kind of use cases.

Anyway, from my point of view, considering this very specific use-case
of ruby-sorbet-runtime, the pattern using ’computed-file’ as ’source’ –
only for having the correct store pathname – is not something that I
would introduce when it is avoidable.

And, maybe I am missing a point, but it appears to me avoidable:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build ruby-sorbet-runtime -S
/gnu/store/ni5mz1j7lbdrdqsvdm5dq1d2ack8c8q6-ruby-sorbet-runtime-0.5.10610.20230106174520-1fa668010-checkout

$ guix hash -r $(guix build ruby-sorbet-runtime -S) $(./pre-inst-env guix build ruby-sorbet-runtime -S)
0agzz44qqq5pxqzzpxwhzlbwwc7x20jrmbmaxj6q8a5bq9ydzws7
0agzz44qqq5pxqzzpxwhzlbwwc7x20jrmbmaxj6q8a5bq9ydzws7
--8<---------------cut here---------------end--------------->8---

using a ’snippet’ – see below.  Basically, ’file-name’ does the job for
the correct name and the other part is just moving content around.
Well, I guess this snippet could be simplified.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: snippet.patch --]
[-- Type: text/x-diff, Size: 1659 bytes --]

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 1dcd5f76a5..f61044f76b 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -14078,7 +14078,35 @@ (define-public ruby-sorbet-runtime
   (package
     (name "ruby-sorbet-runtime")
     (version sorbet-version)
-    (source (make-sorbet-gem-source "runtime"))
+    (source
+     (origin
+       (inherit sorbet-monorepo)
+       (file-name (git-file-name name version))
+       (modules '((guix build utils)
+                  (ice-9 ftw)))
+       (snippet
+        #~(begin
+            (use-modules (guix build utils))
+            (let* ((name "runtime")
+                   (gems "gems")
+                   (gem (string-append gems "/sorbet-" name)))
+              (for-each
+               (lambda (x)
+                 (unless (or (string=? "." x)
+                             (string=? ".." x))
+                   (delete-file-recursively x)))
+               (scandir "."
+                        (lambda (x)
+                          (and (eq? (stat:type (stat x)) 'directory)
+                               (not (string-prefix? gems x))))))
+              (for-each
+               delete-file
+               (find-files "."
+                           (lambda (x _)
+                             (not (string-prefix? (string-append "./" gems) x)))
+                           #:directories? #f))
+              (copy-recursively gem ".")
+              (delete-file-recursively gems))))))
     (build-system ruby-build-system)
     ;; 25 out of 841 tests currently fail, seemingly due to invalid
     ;; assumptions about file names in the build environment (see:

[-- Attachment #3: Type: text/plain, Size: 16 bytes --]



Cheers,
simon

  reply	other threads:[~2023-04-28 18:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09  9:48 bug#62071: openjdk@9/10 sources not reproducible Lars-Dominik Braun
2023-03-11 23:06 ` Björn Höfling
2023-03-12 21:00 ` Björn Höfling
2023-03-13 13:50   ` Simon Tournier
2023-03-16  9:12   ` Björn Höfling
2023-03-16 11:48   ` Ludovic Courtès
2023-03-17 22:10     ` Björn Höfling
2023-03-20  9:08       ` Ludovic Courtès
2023-04-03 21:52         ` Simon Tournier
2023-04-03 21:42     ` SWH: extend sources.json and Mercurial (or not Git and not tarball) Simon Tournier
2023-04-24 16:41       ` Adding content-addressed URLs to https://guix.gnu.org/sources.json Ludovic Courtès
2023-04-25  9:59         ` Simon Tournier
2023-04-25 12:40           ` Ludovic Courtès
2023-04-25 12:59           ` Ludovic Courtès
2023-04-25 13:52           ` Maxim Cournoyer
2023-04-28 13:39             ` Simon Tournier [this message]
2023-05-01  0:39               ` Maxim Cournoyer
2023-05-02  7:39                 ` Ludovic Courtès
2023-05-02 12:52                   ` Maxim Cournoyer
2023-05-02 17:35                     ` Simon Tournier
2023-05-04  7:13                     ` Ludovic Courtès
2023-05-07 21:25                       ` Ludovic Courtès
2023-05-08  1:06                         ` Maxim Cournoyer
2023-03-16 12:37 ` bug#62071: openjdk@9/10 sources not reproducible Jonathan Brielmaier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8hg9lct.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=bjoern.hoefling@bjoernhoefling.de \
    --cc=guix-devel@gnu.org \
    --cc=lars@6xq.net \
    --cc=ludovic.courtes@inria.fr \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.