unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Mark H Weaver <mhw@netris.org>
Cc: 40612@debbugs.gnu.org
Subject: bug#40612: guix build system --dry-run is broken
Date: Tue, 21 Apr 2020 16:48:08 +0200	[thread overview]
Message-ID: <87a734yjx3.fsf@gnu.org> (raw)
In-Reply-To: <87mu775elg.fsf@netris.org> (Mark H. Weaver's message of "Sun, 19 Apr 2020 17:50:56 -0400")

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> wrote:
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Yes, of course, I agree that it's not possible to present a build plan
>>> ahead of time when grafts are enabled.  That was the case before these
>>> changes, and it's the case today.
>>>
>>> The only part I don't understand is why you decided that "--dry-run"
>>> should no longer imply "--no-grafts".  Does it work better for other
>>> people?  For me, the "--dry-run" output has become utterly useless
>>> unless "--no-grafts" is included.
>>
>> I explained the pros and cons of having ‘--dry-run’ no longer implying
>> ‘--with-grafts’ here:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00337.html
>
> I read that message, but was unable to find any mention of the 'pros' of
> having '--dry-run' no longer imply '--no-grafts'.  Did I miss it?  I
> still don't know what is the argument in favor of that change.

The “pro” is not there, you’re right.  It’s basically about eliminating
a special case.  The ideal would be that the special case is unnecessary
and grafts can be considered a special case of dynamic dependencies.

I’m not saying we’re there yet, I pointed out weaknesses and you found
other instances, but that’s the general direction I wanted to take.

>> ‘guix package --dry-run’ overall works well IME, except when a
>> dependency of a fixed-output derivation is missing, as explained above.
>>
>> ‘guix system’ doesn’t work so well as you note (though again, that
>> depends on what you’re building vs. what you have in store).
>
> For what it's worth, I've found the --dry-run output to be similarly
> useless when rebuilding my user profile as well.

Not for me, but we could look at specific examples.

Whether substitutes are used makes no difference, which is an
improvement compared to the previous situation!

Thanks for your feedback,
Ludo’.

      reply	other threads:[~2020-04-21 14:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13 21:31 bug#40612: guix build system --dry-run is broken Mark H Weaver
2020-04-14 15:16 ` Björn Höfling
2020-04-15 16:56   ` Ludovic Courtès
2020-04-17 19:50     ` Mark H Weaver
2020-04-18 16:53       ` Ludovic Courtès
2020-04-19 21:50         ` Mark H Weaver
2020-04-21 14:48           ` Ludovic Courtès [this message]

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=87a734yjx3.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=40612@debbugs.gnu.org \
    --cc=mhw@netris.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).