unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 45891@debbugs.gnu.org
Subject: [bug#45891] [PATCH] packages: 'patch-and-repack' returns a directory when given a directory.
Date: Mon, 18 Jan 2021 01:24:02 -0500	[thread overview]
Message-ID: <87v9bukbjx.fsf@gmail.com> (raw)
In-Reply-To: <87lfcsy3jd.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sat, 16 Jan 2021 22:28:54 +0100")

Hi Ludo,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Previously, 'patch-and-repack' would always create a tar.xz archive as a
>>> result, even if the input was a directory (a checkout).  This change
>>> reduces gratuitous CPU and storage overhead.
>>
>> I like it!
>>
>> Note that on core-updates, xz compression is relatively fast on modern
>> machines as it can do multi-threading.  About space the savings; could
>> the 'temporary' pristine source be cleared from the store always?
>
> No, it’s not possible—the GC will remove what’s unreachable when it
> eventually runs.

OK.

>
>>>    (define (tarxz-name file-name)
>>>      ;; Return a '.tar.xz' file name based on FILE-NAME.
>>> -    (let ((base (cond ((numeric-extension? file-name)
>>> -                       original-file-name)
>>> -                      ((checkout? file-name)
>>> -                       (string-drop-right file-name 9))
>>> -                      (else (file-sans-extension file-name)))))
>>> +    (let ((base (if (numeric-extension? file-name)
>>> +                    original-file-name
>>> +                    (file-sans-extension file-name))))
>>
>> This is not new code, but I'm wondering what's the purpose of
>> numeric-extension?
>
> It’s for file names like “hello-2.10”, where you wouldn’t want to strip
> “.10”.  (Such file names should be rare, but it’s not impossible.)

Ah! Thanks for explaining.

>> What kind of files does it expect to catch?  Also, what happened to
>> stripping the '-checkout' suffix that used to be done?  It doesn't
>> seem like it will happen anymore.
>
> Stripping “-checkout” is no longer necessary because for these we keep
> the original name.
>
>>> -    (let ((name (tarxz-name original-file-name)))
>>> +    (let ((name (if (checkout? original-file-name)
>>> +                    original-file-name
>>> +                    (tarxz-name original-file-name))))
>>>        (gexp->derivation name build
>>>                          #:graft? #f
>>>                          #:system system
>>
>> Was these cases (tar archive source derivation, directory source
>> derivation) already covered by tests under tests/packages.cm?  How did
>> you otherwise test it?  World rebuilding changes are not fun to test
>> without unit tests.
>
> In this case I rebuilt the world and tested ‘guix build -S’ on a
> git-fetch package with a snippet, but I agree that’s super expensive (I
> tested the handful of commits I recently pushed to ‘core-updates’ at the
> same time.)
>
> There are no unit tests specifically for this procedure, but I think
> we’ll quickly find out if it doesn’t behave as intended.
>
> WDYT?

LGTM.  Feel free to push!  About my related change that we thought was
conflicting with this one; it at least applies on top of your change,
and only one test fails currently, I'm working on a fix.

Feel free to push to core-updates!

Thank you,

Maxim




  reply	other threads:[~2021-01-18  6:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 13:15 [bug#45891] [PATCH] packages: 'patch-and-repack' returns a directory when given a directory Ludovic Courtès
2021-01-15 22:14 ` Maxim Cournoyer
2021-01-16 21:28   ` Ludovic Courtès
2021-01-18  6:24     ` Maxim Cournoyer [this message]
2021-01-18 14:56       ` bug#45891: " Ludovic Courtès

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=87v9bukbjx.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=45891@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 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).