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-05 18:55 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2015-10-04 19:57 +0300) wrote:
>>>
> [...]
>>>> 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?
>
> I don't see a problem here, since a fake sha256 may be any string, 

Not really, since ‘base32’ is a macro that checks its argument at
expansion time.  So in practice one cannot C-M-x a package with a random
base32 string.

> for example "" (an empty string).  Also I believe people begin to
> write a new package from some template, so you have a working skeleton
> of future package with all required fields from the very beginning.
> Then after filling an origin 'uri', you could "C-c . s" to download
> the source and get its hash.

Hmm.  I’m skeptical.  :-)

What about, instead, providing an interactive function that would prompt
for a URL, run ‘guix download’ on that, and emit an ‘origin’ template at
point with all the info?

> Oh, now I see what you mean.  Well, I don't know, I think if a user has
> a habbit to check a signature, he will check it anyway; and if not, then
> not.  Besides, at first a packager needs to find an URL of the source
> tarball, so he will meet a signature anyway, if it exists.  So it's up
> to him if he checks it or not.

(Him or her.)

I think we really want to give packagers a strong incentive to check
signatures.  Tools should make it easy to do that.

>>>>> 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?
>
> Indeed, I agree.  So if you don't mind the “download” command, then
> since there will be 2 commands for working with the source of the
> current package, what about the following key bindings for them:
>
> "C-c . s d" - to download the source (to know its hash)
> "C-c . s b" - to build it

Sounds good!

Thanks,
Ludo’.