[bug#51307] [PATCH 0/2] guix hash: eases conversion

[zimoun]

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