From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 51307@debbugs.gnu.org
Subject: [bug#51307] [PATCH 0/2] guix hash: eases conversion
Date: Tue, 09 Nov 2021 10:18:01 +0100 [thread overview]
Message-ID: <86zgqdbsc6.fsf@gmail.com> (raw)
In-Reply-To: <87mtmppa0a.fsf@gnu.org>
Hi Ludo,
On Sun, 31 Oct 2021 at 15:03, Ludovic Courtès <ludo@gnu.org> wrote:
[...]
>> The patch is printing the hash of upstream and it is the only hash which
>> matters – speaking both about packaging and about Disarchive.
>> Therefore, there is no ambiguity here.
>
> Sorry, I think I wasn’t clear. Consider this:
>
> touch ceph
> guix hash ceph
>
> What does it print?
It would print the first clause. Two things: 1. How many times do you
run “guix hash foo” inside a folder where there is a folder or file
’foo’? and 2. It is easy to document this corner case and “guix hash
./ceph” fixes the issue.
Well, the root is that I disagree with your comment, I guess. :-)
The way I see it, ‘guix hash’ is a low-level tool and it should
do what I ask for and not try to second-guess.
Bah it is similar as Garbage Collector debate; Pythonista says: devs are
too dumb for managing memory by themselves, it has to be done
automatically; C devs says: managing memory is too important for
second-guessing dev intent. ;-)
Note that from my understanding, “guix hash” and “guix download” are
somehow redundant, i.e., “guix download” should be included to “guix
hash”. Another story… but I was not drifting yet. ;-)
> If the result depends on external context (the presence or not of a
> ‘ceph’ file in $PWD), that’s a brittle interface IMO.
I trust your experience on designing interfaces. :-)
> This could be addressed by requiring users to be explicit, along these
> lines:
>
> guix hash ceph # compute the hash of the file called ‘ceph’
> guix hash -P ceph # print the hash of the ‘ceph’ package
Well, let’s go for that. One last question about bikeshedding, what
should do
guix hash -P ceph ceph
? Print twice hash of ceph package? Or print hash of ceph package and
hash of ceph file?
> But there’s another issue with the interface: ‘guix hash -P ceph’ would
> merely print the hash as it appears in the package definition. Thus
> ‘-H’ and ‘-r’ would have no effect, which can be confusing.
Wow, many many options of many many Guix commands cannot be composed.
Aside, these two still open bugs,
<http://issues.guix.gnu.org/issue/50472>
<http://issues.guix.gnu.org/issue/50473>
for instance,
guix package --list-installed --show=hello
guix package --show=hello --list-installed
guix package --list-available --list-installed
guix package --list-installed --list-available
And many more,
guix pull --commit=1234 --branch=core-updates
and so “guix time-machine” too. And I am not speaking about build
transformations.
Bah, ok let’s avoid to add another one. :-) It seems possible to detect
and display a warning that -H or -r does not take effect because -P.
> Yes, maybe? I don’t know. I think it’s important to take a step back:
> perhaps we’re in need of a better tool around SWH and Disarchive, rather
> than just a tool that displays a hash. We already have all the APIs to
> do these things anyway, so if we clarify the use case, we can surely
> glue things together to build a tool that will be more convenient.
> (Maybe you’ve already written scripts to help you?)
I will start to collect my needs and what I am doing when playing with
that. And I will try to put that inside an extension, such as “guix
archival”. It will be a basis for judging if it is worth or not.
No, I do not have scripts. I mean, each time I work on that topic, I
write again and again some quick and dirty stuff coupled to ugly Bash
glue code.
This patch is because I have been annoyed to repeat again and again. :-)
Well, I am going to send another version adding multi FILE, first patch
which is making consensus, and second patch the option --package/-P.
Cheers,
simon
next prev parent reply other threads:[~2021-11-09 9:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 16:50 [bug#51307] [PATCH 0/2] guix hash: eases conversion zimoun
2021-10-20 16:54 ` [bug#51307] [PATCH 1/2] scripts: hash: Improve error handling zimoun
2021-10-20 16:54 ` [bug#51307] [PATCH 2/2] scripts: hash: Support file or package zimoun
2021-10-30 14:48 ` [bug#51307] [PATCH 0/2] guix hash: eases conversion Ludovic Courtès
2021-10-30 15:34 ` zimoun
2021-10-30 14:46 ` Ludovic Courtès
2021-10-30 15:40 ` zimoun
2021-10-31 13:43 ` Ludovic Courtès
2021-10-30 14:53 ` Ludovic Courtès
2021-10-30 15:19 ` zimoun
2021-10-30 15:24 ` zimoun
2021-10-31 14:03 ` Ludovic Courtès
2021-11-09 9:18 ` zimoun [this message]
2021-10-31 14:48 ` [bug#51307] Content hashes and file tree serialization methods Ludovic Courtès
2021-11-18 0:29 ` zimoun
2021-11-18 0:20 ` [bug#51307] [PATCH v2 0/3] scripts: hash: Several files and serializer zimoun
2021-11-18 0:20 ` [bug#51307] [PATCH v2 1/3] scripts: hash: Support several files zimoun
2021-12-17 16:17 ` Ludovic Courtès
2021-11-18 0:20 ` [bug#51307] [PATCH v2 2/3] scripts: hash: Add 'serializer' option zimoun
2021-12-17 16:17 ` Ludovic Courtès
2021-11-18 0:20 ` [bug#51307] [PATCH v2 3/3] scripts: hash: Add git serializer zimoun
[not found] ` <87bl1bjsxf.fsf@gnu.org>
[not found] ` <CAJ3okZ00+BSw=nuhGP8NTwU8ZmitzrfFzTw0WecsOB9rZ+hG_g@mail.gmail.com>
2021-12-21 9:09 ` Ludovic Courtès
2021-12-15 8:06 ` [bug#51307] [PATCH v2 0/3] scripts: hash: Several files and serializer zimoun
2021-12-15 10:05 ` 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=86zgqdbsc6.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=51307@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).