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
next prev parent 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.