Alex Kost <alez...@gmail.com> skribis:
> Ludovic Courtès (2015-10-08 01:10 +0300) wrote:
>
> [...]
>>>>> 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. :-)
>>>
>>> Sorry, I didn't get it. Skeptical that people start from a template?
>>
>> Yes, it feels weird to me, the idea that an <origin> object with bogus
>> values would be created just for the sake of satisfying the download
>> tool.
>
> Hm, I have an opposite opinion: for me it is weird to write a package
> from scratch. I usually start from a package template that has all
> required fields (including <origin>) or even I just copy an existing
> package and then modify the fields I need.
>
> I wonder, do you start to write a package from scratch?
Sometimes I write from scratch, sometimes I use ‘guix import’, sometimes
I copy/paste some other definition.
>> Wouldn’t the explanation in the manual of how to use this be relatively
>> complex? That’s a good benchmark.
>
> As I see it, it is not complex:
>
> «Download a source of the package defined by the current variable
> definition and print its SHA256 hash. This command has the same meaning
> as running @code{guix download} on the package source (@pxref{Invoking
> guix download})»
Hmm OK. (Is it really “current variable definition”, or rather
“‘origin’ form at point”?)
> Anyway, after all I'm not going to add this command to not give people
> an incentive not to check signatures.
Yeah, maybe we can see where the other discussion goes.
The command to call ‘package-source-derivation’ for the package at point
is still welcome, though. :-)
>>>> 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?
>>>
>>> I see several problems here, but the main is: this sounds like it should
>>> be synchronous: you give an URL, wait until the source is downloaded and
>>> finally get the template at point. But downloading can take a VERY long
>>> time, so I don't think it will be a usable command.
>>
>> Good point. But there’s the same problem with what you propose no? The
>> user somehow has to wait for the download to complete?
>
> Well, sure you also need to wait for the download, but your Emacs won't
> be freezed for all this time, so you can do something else while it is
> being downloaded in the REPL.
Right.
Thanks,
Ludo’.
