From: Christopher Lemmer Webber <cwebber@dustycloud.org>
To: "Jakob L. Kreuze" <zerodaysfordays@sdf.lonestar.org>,
David Thompson <dthompson2@worcester.edu>
Cc: 36872@debbugs.gnu.org
Subject: [bug#36872] [PATCH 2/2] remote: Remove '--system' argument.
Date: Wed, 07 Aug 2019 14:31:58 -0400 [thread overview]
Message-ID: <87a7ckq129.fsf@dustycloud.org> (raw)
In-Reply-To: <877e7qvv75.fsf@sdf.lonestar.org>
Jakob L. Kreuze writes:
> Hey Chris!
>
> Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
>
>> I'm still wondering whether asking the remote machine what its
>> architecture is won't turn out to be fragile in some way, though I'm not
>> sure how to articulate how that would be yet. It seems like a weird
>> side effect to apply before doing the build. (What if we want to build
>> derivations when we don't actually have a machine up and running yet?
>> Etc, etc.)
>
> I agree that it isn't the purest solution, but my thinking is that
> 'remote-eval' is meant to be effectful anyway. As for the situation
> where we build derivations for a machine that isn't running yet: I think
> we can cross that bridge when we get to it -- 'guix deploy' doesn't have
> the feature at the moment.
>
> Regards,
> Jakob
I thought about it more between yesterday and today, and it continues to
seem strange to me that we're doing "probing" here. We don't probe to
guess where Guix is currently installed or etc to specify disks. I
guess that's not the same thing, but...
Here's the concern: imagine that we want to be able to up-front do
something like "guix system build" before we even start spinning up
servers. Does this block that direction?
Dave, your input appreciated on this one.
I'm not sure I want to block the patch series with my hand wringing, but
I do want to make sure we give it appropriate consideration.
- Chris
next prev parent reply other threads:[~2019-08-07 18:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 13:41 [bug#36872] [PATCH 1/2] remote: Build derivations appropriate for the remote's architecture Jakob L. Kreuze
2019-07-31 13:43 ` [bug#36872] [PATCH 2/2] remote: Remove '--system' argument Jakob L. Kreuze
2019-08-06 20:57 ` Christopher Lemmer Webber
2019-08-06 20:58 ` [bug#36872] [PATCH v2 1/2] remote: Build derivations appropriate for the remote's Jakob L. Kreuze
2019-08-06 20:59 ` [bug#36872] [PATCH v2 2/2] remote: Remove '--system' argument Jakob L. Kreuze
2019-08-06 21:29 ` [bug#36872] [PATCH " Jakob L. Kreuze
2019-08-07 18:31 ` Christopher Lemmer Webber [this message]
2019-08-07 19:03 ` Thompson, David
2019-08-07 20:28 ` Jakob L. Kreuze
2019-08-09 18:24 ` [bug#36872] [PATCH v2 1/2] remote: Build derivations appropriate for the remote's Jakob L. Kreuze
2019-08-09 18:25 ` [bug#36872] [PATCH v2 2/2] remote: Remove '--system' argument Jakob L. Kreuze
2019-08-14 19:40 ` Christopher Lemmer Webber
2019-08-14 20:29 ` bug#36872: " Christopher Lemmer Webber
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7ckq129.fsf@dustycloud.org \
--to=cwebber@dustycloud.org \
--cc=36872@debbugs.gnu.org \
--cc=dthompson2@worcester.edu \
--cc=zerodaysfordays@sdf.lonestar.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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).