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

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-10-08 14:46 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2015-10-08 01:10 +0300) wrote:
>>>
>>> [...]
 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”?)
>
> As I said before it's the same as "C-c . b" is used for downloading the
> package source, i.e. it is performed "on the current variable
> definition".  It is not possible to make it "on origin at point",
> because most of the times it has a reference to 'version' ('name'):
>
> (origin
>   ...
>   (uri (string-append "http://...; version ".tar.gz")))
>
> and 'version' is known only for the whole package, not for the 'origin'.

Oh right.  Thanks for bearing with me!

Ludo’.

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

[Alex Kost]

Ian Denhardt (2015-10-07 22:15 +0300) wrote:

> What about just having command line (non-emacs) tool? I'm thinking
> something inspired by Archlinux's `makepkg -g`, which downloads the
> sources based on the current build script and outputs something that can
> just be copied into it. I don't feel I have the full picture re: how
> that interacts with the macro's checking, but we could fall back on the
> user supplying URLs.

IIUC such a tool would also have the same problem (an incentive not to
check signatures).

-- 
Alex

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

[Alex Kost]

Ludovic Courtès (2015-10-08 14:46 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-10-08 01:10 +0300) wrote:
>>
>> [...]
>>> 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”?)

As I said before it's the same as "C-c . b" is used for downloading the
package source, i.e. it is performed "on the current variable
definition".  It is not possible to make it "on origin at point",
because most of the times it has a reference to 'version' ('name'):

(origin
  ...
  (uri (string-append "http://...; version ".tar.gz")))

and 'version' is known only for the whole package, not for the 'origin'.

>> 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.  :-)

OK.

-- 
Alex

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

[Alex Kost]

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  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 ) 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?

> 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})»

Anyway, after all I'm not going to add this command to not give people
an incentive not to check signatures.

>>> 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.

>>> (Him or her.)
>>
>> Yes, I just always say/write "he", "him", etc.
>
> Yeah, but I think it’s best to try and avoid this language bias (see
> .)  We want to
> welcome all human beings to our Guix party, don’t we?  :-)

Wow, I didn't realize it could be counted as an offence.  In Russian (my
native language) a phrase "A user does something, because he ..." is
absolutely neutral.  Thanks for the info!

-- 
Alex

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

[Ludovic Courtès]

Alex Kost  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  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 ) 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’.

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

[Christopher Allan Webber]

Alex Kost writes:

> 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  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 ) 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?

I think helpers to get people started are useful.  I cannot remember
fields from memory, not just in Guix, but in pretty much all code.  Thus
I ususally look at other code examples to remember how things work.
Sometimes I set up yasnippet expansion templates in emacs.

So, just a vote for: helpers are helpful!

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

[Ludovic Courtès]

Christopher Allan Webber  skribis:

> Alex Kost writes:
>
>> 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  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 ) 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?
>
> I think helpers to get people started are useful.  I cannot remember
> fields from memory, not just in Guix, but in pretty much all code.  Thus
> I ususally look at other code examples to remember how things work.
> Sometimes I set up yasnippet expansion templates in emacs.

Yes I think it’s good to have something that generates a template.

I’ve always had on my to-do list some sort of a catch-all importer:
you’d give it a tarball URL, and it’d produce a template with the right
build system, maybe some dependencies inferred from configure.ac or
CMakeLists.txt or setup.py, etc.

Ludo’.

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

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-10-07 15:23 +0300) wrote:
>
>> Alex Kost  skribis:
>>
> [...]
>>> 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.
>
> Ah, indeed, it can't be any string, but it can be an empty string
> (perhaps it's a bug in ‘base32’?)

Oh right.  It’s not really a bug, since the empty string is a valid
base32 representation of the empty bytevector.

>>> 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  object with bogus
values would be created just for the sake of satisfying the download
tool.

Wouldn’t the explanation in the manual of how to use this be relatively
complex?  That’s a good benchmark.

>> 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?

>> (Him or her.)
>
> Yes, I just always say/write "he", "him", etc.

Yeah, but I think it’s best to try and avoid this language bias (see
.)  We want to
welcome all human beings to our Guix party, don’t we?  :-)

Thanks,
Ludo’.

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

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-10-05 18:55 +0300) wrote:
>
>> Alex Kost  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’.

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

[Alex Kost]

Ludovic Courtès (2015-10-07 15:23 +0300) wrote:

> Alex Kost  skribis:
>
[...]
>> 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.

Ah, indeed, it can't be any string, but it can be an empty string
(perhaps it's a bug in ‘base32’?)

>> 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?
Or that one can download a source after filling an origin 'uri'?  If the
latter, I definitely did it.

> 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.

>> 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.)

Yes, I just always say/write "he", "him", etc.

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

OK, I understand.

-- 
Alex

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

[Ian Denhardt]

Quoting Alex Kost (2015-10-07 13:25:44)
> > 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.

What about just having command line (non-emacs) tool? I'm thinking
something inspired by Archlinux's `makepkg -g`, which downloads the
sources based on the current build script and outputs something that can
just be copied into it. I don't feel I have the full picture re: how
that interacts with the macro's checking, but we could fall back on the
user supplying URLs.

-Ian


signature.asc
Description: signature

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

[Alex Kost]

Ludovic Courtès (2015-10-05 18:55 +0300) wrote:

> Alex Kost  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, 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.

>>> 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.

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.

(I confess that I never check 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?

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

-- 
Alex

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

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-10-04 19:57 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> Ludovic Courtès (2015-10-03 23:35 +0300) wrote:
>>>
 Alex Kost  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’.

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

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-10-03 23:35 +0300) wrote:
>
>> Alex Kost  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?

In that case, I would suggest something based on the URL at point rather
than the origin at point.

However, if this is “too convenient”, I’m afraid this would give an
incentive to not check OpenPGP signatures when they are available.

> 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.

Thanks,
Ludo’.

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

[Alex Kost]

Ludovic Courtès (2015-10-04 19:57 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-10-03 23:35 +0300) wrote:
>>
>>> Alex Kost  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.

> 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.

> 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 :-(

>> 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.

-- 
Alex

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

[Ludovic Courtès]

Alex Kost  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?

Thanks,
Ludo’.

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

[Alex Kost]

* 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.
---
 doc/emacs.texi  |  6 ++
 emacs/guix-devel.el | 14 ++
 2 files changed, 20 insertions(+)

diff --git a/doc/emacs.texi b/doc/emacs.texi
index b6f2701..00f86f3 100644
--- a/doc/emacs.texi
+++ b/doc/emacs.texi
@@ -667,6 +667,12 @@ this command---for example, with @kbd{C-M-x} (@pxref{To 
eval or not to
 eval,,, geiser, Geiser User Manual})
 (@code{guix-devel-build-package-definition}).
 
+@item C-c . s
+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}) (@code{guix-devel-download-package-source}).
+
 @end table
 
 Unluckily, there is a limitation related to long-running REPL commands.
diff --git a/emacs/guix-devel.el b/emacs/guix-devel.el
index ee7629f..a8167a0 100644
--- a/emacs/guix-devel.el
+++ b/emacs/guix-devel.el
@@ -69,6 +69,7 @@ Interactively, use the module defined by the current scheme 
file."
 (defun guix-devel-setup-repl ( repl)
   "Setup REPL for using `guix-devel-...' commands."
   (guix-devel-use-modules "(guix monad-repl)"
+  "(guix packages)"
   "(guix scripts)"
   "(guix store)")
   ;; Without this workaround, the build output disappears.  See
@@ -113,6 +114,18 @@ run BODY."
   guix-use-substitutes)
 "#:dry-run?" (guix-guile-boolean guix-dry-run)))
 
+(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)
+
 
 ;;; Font-lock
 
@@ -151,6 +164,7 @@ to find 'modify-phases' keywords."
 (defvar guix-devel-keys-map
   (let ((map (make-sparse-keymap)))
 (define-key map (kbd "b") 'guix-devel-build-package-definition)
+(define-key map (kbd "s") 'guix-devel-download-package-source)
 (define-key map (kbd "k") 'guix-devel-copy-module-as-kill)
 (define-key map (kbd "u") 'guix-devel-use-module)
 map)
-- 
2.5.0