Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.

[ludo@gnu.org (Ludovic Courtès)]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2015-10-04 19:57 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2015-10-03 23:35 +0300) wrote:
>>>
>>>> Alex Kost <alezost@gmail.com> skribis:
>>>>
>>>>> * emacs/guix-devel.el (guix-devel-setup-repl): Use (guix packages) module.
>>>>>   (guix-devel-download-package-source): New command.
>>>>>   (guix-devel-keys-map): Add key binding for it.
>>>>> * doc/emacs.texi (Emacs Development): Document it.
>>>>
>>>> [...]
>>>>
>>>>> +(defun guix-devel-download-package-source ()
>>>>> +  "Download the source of the current package.
>>>>> +Use this function to compute SHA256 hash of the package source."
>>>>> +  (interactive)
>>>>> +  (guix-devel-with-definition def
>>>>> +    (guix-devel-use-modules "(guix scripts download)")
>>>>> +    (when (or (not guix-operation-confirm)
>>>>> +              (y-or-n-p (format "Download '%s' package source?" def)))
>>>>> +      (guix-geiser-eval-in-repl
>>>>> +       (format "(guix-download (origin-uri (package-source %s)))"
>>>>> +               def)))))
>>>>
>>>> What about instead building the ‘package-source-derivation’ of the
>>>> package?  That way, that would do the exact same thing as ‘guix build
>>>> -S’ and would work not only with ‘url-fetch’ but also with the other
>>>> things.
>>>>
>>>> WDYT?
>>>
>>> The goal of this command is to display a hash.
>>
>> So this would be something one would use as they write a package
>> definition, to fill in the ‘sha256’ field, right?
>
> Exactly.  For example, here is how I update a package using Geiser:
>
> - I modify its 'version' field,
> - "C-M-x" to reevaluate the package definition,
> - "C-c . s" to download the new source and show its hash,
> - replace the old hash with the new one,
> - and finally "C-c . b" to build the new version of package.

OK, nice.

>> In that case, I would suggest something based on the URL at point rather
>> than the origin at point.
>
> It's neither URL at point, nor origin at point: it's like "C-c . b" but
> to download the source of the current package definition instead of
> building it.
>
> Also I don't understand how it can be based on the URL at point as
> instead of the full URL, we have something like this:
>
>   (uri (string-append "http://.../foo-" version ".tar.xz"))
>
> So currently to use "guix download", at first you need to manually
> construct the full URL.  I find this inconvenient, that's why I want to
> have a command to download a source of the current package and to
> display its hash.

Yes, that make sense.

The problem I had in mind was that, when writing a new package
definition from scratch, you don’t know the SHA256 yet, but ‘sha256’ is
a required field of ‘origin’.  So one would have to write a fake
‘sha256’ value just for the sake of being able to use that feature,
which seems odd to me.

See what I mean?  How would you handle such a case?

>> However, if this is “too convenient”, I’m afraid this would give an
>> incentive to not check OpenPGP signatures when they are available.
>
> Sorry, I have no idea what it means :-(

When upstream digitally signs its source code tarballs, packagers should
check those signatures to authenticate the code they have.

If the tool makes it too easy to fill out the ‘sha256’ field without
going through the trouble of downloading the ‘.sig’ file and checking
it, then people will have an incentive not to check those signatures.

>>> At first I also thought about building a package source and then to
>>> calculate the hash of the store file, but this way will lead to the
>>> wrong hashes for "snippet"-ed origins.  Or do I miss anything?
>>
>> Well, I think bindings for ‘package-source-derivation’ would also be
>> useful, but IIUC this is not what you had in mind.
>
> If you mean to make a command to build the current package source, it
> can be done, although I don't see how it can be useful.

It’s occasionally useful, similar to ‘guix build -S’ or the “Show”
button in package info buffers, except that it would operate directly on
the package at point.

WDYT?

Thanks,
Ludo’.