all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Clément Lassieur" <clement@lassieur.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 31813@debbugs.gnu.org
Subject: [bug#31813] [PATCH] evaluate: Use a generic key to identify Cuirass arguments.
Date: Fri, 15 Jun 2018 15:40:26 +0200	[thread overview]
Message-ID: <87bmcctbg5.fsf@lassieur.org> (raw)
In-Reply-To: <87tvq4v1x7.fsf@gnu.org>

Heya!

Ludovic Courtès <ludo@gnu.org> writes:

>>>> @@ -98,7 +99,7 @@ building things during evaluation~%")
>>>>                  (proc    (module-ref %user-module proc-name))
>>>>                  (commit  (assq-ref spec #:current-commit))
>>>>                  (name    (assq-ref spec #:name))
>>>> -                (args    `((,(string->symbol name)
>>>> +                (args    `((guix
>>>>                              (revision . ,commit)
>>>>                              (file-name . ,source))
>>>>                             ,@(or (assq-ref spec #:arguments) '())))
>>>
>>> If we do that, then everything is called ‘guix’.
>>
>> Why is it a problem?
>
> In theory you can have several inputs (checkouts) to a given jobset, and
> they need to have different names so that you can distinguish among
> them.

Right now 'cuirass-jobs' can't handle several checkouts, and evaluate.in
sends only one 'checkout'.  So if we want to support several inputs we
would need to modify both Guix and Cuirass.

And anyway if we force the argument key to 'guix', 'guix-checkout' or
'guix-modular', it wouldn't prevent us to add other inputs (checkouts)
later, I think.

>> I don't think the current situation is good because:
>>   - a simple mistake from the user gets their build task to silently
>>     vanish,
>>   - it is inconvenient to use guix-modular.scm with several different
>>     specifications,
>>   - that #:name key is useless if users can't choose a custom name,
>>   - allowing custom names would make it way easier to understand
>>     /api/latestbuilds.  For an example with custom names, see
>>     https://cuirass.lassieur.org:8081/api/latestbuilds?nr=100.
>
> I agree with all this.  :-)  I think the custom name should appear in
> the arguments passed to the build procedure, though.

But with our patch it *does* appear in the build procedure, because it
is still in 'eval' which is read by 'evaluate' in src/cuirass/base.scm.

--8<---------------cut here---------------start------------->8---
                (eval    `((#:specification . ,name)
                           (#:revision . ,commit)))
           pretty-print
            `(evaluation ,eval
                         ,(map (lambda (thunk) (thunk))
                               thunks))
--8<---------------cut here---------------end--------------->8---

What we want to modify is the key passed to 'proc', and it is only used
to extract the checkout argument (with 'assq-ref').

>> Using an auto-incrementing ID column could work, but I don't like it
>> for the reasons I explained above.
>
> You didn’t mention auto-incrementing ID above, did you?  It would seem
> like a simple solution to the problem.

If we were to do this,
  - that would allow several specs to have the same name,
  - that would not change the fact that users are forced to use the
    'guix-modular' (or 'guix') name for each spec.

The former is nice but not necessary (it could be a further commit), the
latter is the bug that we want to fix.

Mathieu and Clément

  reply	other threads:[~2018-06-15 13:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-13 13:50 [bug#31813] [PATCH] evaluate: Use a generic key to identify Cuirass arguments Clément Lassieur
2018-06-13 13:58 ` Mathieu Othacehe
2018-06-14 20:42 ` Ludovic Courtès
2018-06-14 23:03   ` Clément Lassieur
2018-06-15  9:23     ` Ludovic Courtès
2018-06-15 13:40       ` Clément Lassieur [this message]
2018-06-16  8:45         ` Ludovic Courtès
2018-06-18 16:16           ` bug#31813: " Clément Lassieur

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=87bmcctbg5.fsf@lassieur.org \
    --to=clement@lassieur.org \
    --cc=31813@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /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.