[PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[David Thompson]

* guix/build/emacs-build-system.scm (gnu:unpack)
(store-file->elisp-source-file, unpack): New procedures.
(%standard-phases): Use the new unpack procedure.
---
 guix/build/emacs-build-system.scm | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/guix/build/emacs-build-system.scm b/guix/build/emacs-build-system.scm
index f0a9a6e..4fd36d1 100644
--- a/guix/build/emacs-build-system.scm
+++ b/guix/build/emacs-build-system.scm
@@ -21,6 +21,7 @@
   #:use-module (guix build utils)
   #:use-module (guix build emacs-utils)
   #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-11)
   #:use-module (srfi srfi-26)
   #:use-module (ice-9 rdelim)
   #:use-module (ice-9 regex)
@@ -39,6 +40,27 @@
 ;; archive signature.
 (define %install-suffix "/share/emacs/site-lisp/guix.d")
 
+(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
+
+(define (store-file->elisp-source-file file)
+  "Convert file, a store file name for an Emacs Lisp source file, into a file
+name that has been stripped of the hash and version number."
+  (let-values (((name version)
+                (package-name->name+version
+                 (strip-store-file-name file))))
+    (string-append name ".el")))
+
+(define* (unpack #:key source #:allow-other-keys)
+  "Unpack SOURCE into the build directory.  SOURCE may be a compressed
+archive, a directory, or an Emacs Lisp file."
+  (if (string-suffix? ".el" source)
+      (begin
+        (mkdir "source")
+        (chdir "source")
+        (copy-file source (store-file->elisp-source-file source))
+        #t)
+      (gnu:unpack #:source source)))
+
 (define* (build #:key outputs inputs #:allow-other-keys)
   "Compile .el files."
   (let* ((emacs (string-append (assoc-ref inputs "emacs") "/bin/emacs"))
@@ -151,6 +173,7 @@ second hyphen.  This corresponds to 'name-version' as used in ELPA packages."
 
 (define %standard-phases
   (modify-phases gnu:%standard-phases
+    (replace 'unpack unpack)
     (delete 'configure)
     (delete 'check)
     (delete 'install)
-- 
2.7.3

[PATCH 2/2] gnu: Add emacs-better-defaults.

[David Thompson]

* gnu/packages/emacs.scm (emacs-better-defaults): New variable.
---
 gnu/packages/emacs.scm | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 5d6db5a..105c25d 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -1706,3 +1706,24 @@ It is recommended to use @code{clojure-mode} with paredit or smartparens.")
 The purpose of this library is to wrap all the quirks and hassle of
 @code{package.el} into a sane API.")
     (license license:gpl3+)))
+
+(define-public emacs-better-defaults
+  (package
+    (name "emacs-better-defaults")
+    (version "0.1.3")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "http://stable.melpa.org/packages/better-defaults-"
+                           version ".el"))
+       (sha256
+        (base32
+         "0lvpmja8i8v10lbcvzj6pd7vn9c7gnlbcddd416g2pjq0yydydgf"))))
+    (build-system emacs-build-system)
+    (home-page "https://github.com/technomancy/better-defaults")
+    (synopsis "Better defaults for Emacs")
+    (description
+     "Better defaults attempts to address the most obvious deficiencies of the
+Emacs default configuration in uncontroversial ways that nearly everyone can
+agree upon.")
+    (license license:gpl3+)))
-- 
2.7.3

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Alex Kost]

David Thompson (2016-05-27 17:10 +0300) wrote:

> * gnu/packages/emacs.scm (emacs-better-defaults): New variable.
> ---
>  gnu/packages/emacs.scm | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 5d6db5a..105c25d 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -1706,3 +1706,24 @@ It is recommended to use @code{clojure-mode} with paredit or smartparens.")
>  The purpose of this library is to wrap all the quirks and hassle of
>  @code{package.el} into a sane API.")
>      (license license:gpl3+)))
> +
> +(define-public emacs-better-defaults
> +  (package
> +    (name "emacs-better-defaults")
> +    (version "0.1.3")
> +    (source
> +     (origin
> +       (method url-fetch)
> +       (uri (string-append "http://stable.melpa.org/packages/better-defaults-"
> +                           version ".el"))

My understanding is that we prefer to retrieve a source directly from
the upstream, so it is better to use:

  https://github.com/technomancy/better-defaults/archive/0.1.3.tar.gz

Otherwise, LGTM.

> +       (sha256
> +        (base32
> +         "0lvpmja8i8v10lbcvzj6pd7vn9c7gnlbcddd416g2pjq0yydydgf"))))
> +    (build-system emacs-build-system)
> +    (home-page "https://github.com/technomancy/better-defaults")
> +    (synopsis "Better defaults for Emacs")
> +    (description
> +     "Better defaults attempts to address the most obvious deficiencies of the
> +Emacs default configuration in uncontroversial ways that nearly everyone can
> +agree upon.")
> +    (license license:gpl3+)))

-- 
Alex

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

> * gnu/packages/emacs.scm (emacs-better-defaults): New variable.

[...]

> +       (uri (string-append "http://stable.melpa.org/packages/better-defaults-"
> +                           version ".el"))

IIRC, MELPA URLs are not stable over time (modified in place) and for
this reason we usually fetch things from Git instead.

Could you do that here?

Otherwise LGTM, thanks!

Ludo’.

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Thompson, David]

On Sat, May 28, 2016 at 11:37 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> David Thompson <dthompson2@worcester.edu> skribis:
>
>> * gnu/packages/emacs.scm (emacs-better-defaults): New variable.
>
> [...]
>
>> +       (uri (string-append "http://stable.melpa.org/packages/better-defaults-"
>> +                           version ".el"))
>
> IIRC, MELPA URLs are not stable over time (modified in place) and for
> this reason we usually fetch things from Git instead.
>
> Could you do that here?

Fixed and pushed.  Thanks Ludo and Alex!

- Dave

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Mark H Weaver]

"Thompson, David" <dthompson2@worcester.edu> writes:
> Fixed and pushed.  Thanks Ludo and Alex!

It fails to build on Hydra:

  http://hydra.gnu.org/build/1208688 (x86_64)
  http://hydra.gnu.org/build/1208304 (i686)
  http://hydra.gnu.org/build/1208517 (armhf)

Can you take a look?

      Mark

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Thompson, David]

On Tue, May 31, 2016 at 12:59 PM, Mark H Weaver <mhw@netris.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> writes:
>> Fixed and pushed.  Thanks Ludo and Alex!
>
> It fails to build on Hydra:
>
>   http://hydra.gnu.org/build/1208688 (x86_64)
>   http://hydra.gnu.org/build/1208304 (i686)
>   http://hydra.gnu.org/build/1208517 (armhf)

These jobs are for building emacs-constants, contributed by Federico
Beffa in February.  I took a look at the build log and the failure is
in the make-autoloads build phase which this patch set shouldn't have
affected.

- Dave

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Mark H Weaver]

"Thompson, David" <dthompson2@worcester.edu> writes:

> On Tue, May 31, 2016 at 12:59 PM, Mark H Weaver <mhw@netris.org> wrote:
>> "Thompson, David" <dthompson2@worcester.edu> writes:
>>> Fixed and pushed.  Thanks Ludo and Alex!
>>
>> It fails to build on Hydra:
>>
>>   http://hydra.gnu.org/build/1208688 (x86_64)
>>   http://hydra.gnu.org/build/1208304 (i686)
>>   http://hydra.gnu.org/build/1208517 (armhf)
>
> These jobs are for building emacs-constants, contributed by Federico
> Beffa in February.  I took a look at the build log and the failure is
> in the make-autoloads build phase which this patch set shouldn't have
> affected.

Ah, indeed, I stand corrected.  Sorry for the noise.

      Mark

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Alex Kost]

Mark H Weaver (2016-05-31 19:59 +0300) wrote:

> "Thompson, David" <dthompson2@worcester.edu> writes:
>> Fixed and pushed.  Thanks Ludo and Alex!
>
> It fails to build on Hydra:
>
>   http://hydra.gnu.org/build/1208688 (x86_64)
>   http://hydra.gnu.org/build/1208304 (i686)
>   http://hydra.gnu.org/build/1208517 (armhf)

This happened because the source was wrongfully renamed to ".el" while
it should be ".tar.gz".  Fixed by commit
37dbfc50841a8e91f9fb0dc80ff9b5f23de38689.

-- 
Alex

Re: [PATCH 2/2] gnu: Add emacs-better-defaults.

[Thompson, David]

On Tue, May 31, 2016 at 4:53 PM, Alex Kost <alezost@gmail.com> wrote:
> Mark H Weaver (2016-05-31 19:59 +0300) wrote:
>
>> "Thompson, David" <dthompson2@worcester.edu> writes:
>>> Fixed and pushed.  Thanks Ludo and Alex!
>>
>> It fails to build on Hydra:
>>
>>   http://hydra.gnu.org/build/1208688 (x86_64)
>>   http://hydra.gnu.org/build/1208304 (i686)
>>   http://hydra.gnu.org/build/1208517 (armhf)
>
> This happened because the source was wrongfully renamed to ".el" while
> it should be ".tar.gz".  Fixed by commit
> 37dbfc50841a8e91f9fb0dc80ff9b5f23de38689.

Ugh, sorry for that blunder.

- Dave

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Alex Kost]

David Thompson (2016-05-27 17:10 +0300) wrote:

> * guix/build/emacs-build-system.scm (gnu:unpack)
> (store-file->elisp-source-file, unpack): New procedures.
> (%standard-phases): Use the new unpack procedure.

I think there is no need to improve emacs-build-system to handle single
file sources: there is 'uncompressed-file-fetch' method for this
purpose.  Look in (gnu packages emacs) for this procedure and how it is
used (for example, by 'emacs-rfcview' package).

I Cc-ed Federico as he added 'uncompressed-file-fetch'.

-- 
Alex

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Ludovic Courtès]

David Thompson <dthompson2@worcester.edu> skribis:

> * guix/build/emacs-build-system.scm (gnu:unpack)
> (store-file->elisp-source-file, unpack): New procedures.
> (%standard-phases): Use the new unpack procedure.

Good idea, LGTM!

Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
commit, and remove ‘uncompressed-file-fetch’?

Thanks,
Ludo’.

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Alex Kost]

Ludovic Courtès (2016-05-28 18:36 +0300) wrote:

> David Thompson <dthompson2@worcester.edu> skribis:
>
>> * guix/build/emacs-build-system.scm (gnu:unpack)
>> (store-file->elisp-source-file, unpack): New procedures.
>> (%standard-phases): Use the new unpack procedure.
>
> Good idea, LGTM!
>
> Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
> commit, and remove ‘uncompressed-file-fetch’?

I object!  I mean this should be discussed at least.  I would really
prefer to keep (and document) 'uncompressed-file-fetch' and not to
update emacs-build-system for this case.  It is possible, that once
we'll need to handle non-compressed files for another build system.  So
it should also be adjusted in the same way.  But if we keep
'uncompressed-file-fetch', it will be a general decision as it can be
used for any build system.

-- 
Alex

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ludovic Courtès (2016-05-28 18:36 +0300) wrote:
>
>> David Thompson <dthompson2@worcester.edu> skribis:
>>
>>> * guix/build/emacs-build-system.scm (gnu:unpack)
>>> (store-file->elisp-source-file, unpack): New procedures.
>>> (%standard-phases): Use the new unpack procedure.
>>
>> Good idea, LGTM!
>>
>> Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
>> commit, and remove ‘uncompressed-file-fetch’?
>
> I object!

Damn it, sorry, I thought this would be uncontroversial.

> I mean this should be discussed at least.  I would really prefer to
> keep (and document) 'uncompressed-file-fetch' and not to update
> emacs-build-system for this case.  It is possible, that once we'll
> need to handle non-compressed files for another build system.  So it
> should also be adjusted in the same way.  But if we keep
> 'uncompressed-file-fetch', it will be a general decision as it can be
> used for any build system.

In my view, ‘uncompressed-file-fetch’ and the ‘emacs-build-system’
change that Dave proposes are equally good hacks, but the latter has the
advantage that people won’t have to think about it: they can just use
‘url-fetch’ and ‘emacs-build-system’ as usual and things will just work.

Of course, perhaps we should consider handling flat files closer to the
core, but so far the only use case we have, AFAIK, is .el files.  Thus,
it doesn’t seem that bad to add a special case in ‘emacs-build-system’.
Pragmatic approach I suppose.  ;-)

WDYT?

Thanks,
Ludo’.

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Alex Kost]

Ludovic Courtès (2016-05-30 00:50 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2016-05-28 18:36 +0300) wrote:
>>
>>> David Thompson <dthompson2@worcester.edu> skribis:
>>>
>>>> * guix/build/emacs-build-system.scm (gnu:unpack)
>>>> (store-file->elisp-source-file, unpack): New procedures.
>>>> (%standard-phases): Use the new unpack procedure.
>>>
>>> Good idea, LGTM!
>>>
>>> Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
>>> commit, and remove ‘uncompressed-file-fetch’?
>>
>> I object!
>
> Damn it, sorry, I thought this would be uncontroversial.
>
>> I mean this should be discussed at least.  I would really prefer to
>> keep (and document) 'uncompressed-file-fetch' and not to update
>> emacs-build-system for this case.  It is possible, that once we'll
>> need to handle non-compressed files for another build system.  So it
>> should also be adjusted in the same way.  But if we keep
>> 'uncompressed-file-fetch', it will be a general decision as it can be
>> used for any build system.
>
> In my view, ‘uncompressed-file-fetch’ and the ‘emacs-build-system’
> change that Dave proposes are equally good hacks, but the latter has the
> advantage that people won’t have to think about it: they can just use
> ‘url-fetch’ and ‘emacs-build-system’ as usual and things will just work.
>
> Of course, perhaps we should consider handling flat files closer to the
> core, but so far the only use case we have, AFAIK, is .el files.  Thus,
> it doesn’t seem that bad to add a special case in ‘emacs-build-system’.
> Pragmatic approach I suppose.  ;-)
>
> WDYT?

<cough>, OK, I wanted to write verbosely why I prefer
uncompressed-file-fetch, and why we should still use it, etc.;

but I've just noticed an unpleasant downside with
‘uncompressed-file-fetch’: for example, if you build the recently added
"emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
impossible to do (require 'queue).  With David's solution, it will be a
proper "queue.el" file.

So I agree now.  David's patch is definitely a better solution :-)

-- 
Alex

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

2016-05-30 12:14 GMT+02:00 Alex Kost <alezost@gmail.com>:

>
> <cough>, OK, I wanted to write verbosely why I prefer
> uncompressed-file-fetch, and why we should still use it, etc.;
>
> but I've just noticed an unpleasant downside with
> ‘uncompressed-file-fetch’: for example, if you build the recently added
> "emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
> impossible to do (require 'queue).  With David's solution, it will be a
> proper "queue.el" file.
>
> So I agree now.  David's patch is definitely a better solution :-)
>
>
Ah ! This is probably why I couldn't manage emacs-cider to require
emacs-spinner and emacs-queue. They both are packaged with
uncompressed-file-fetch.

In fact queue and spinner work if I installl them on their own.

After I attempt with cider, they not only are not requirable but they are
also not autoloaded anymore.

So now I'll try stick with more tested download methods and see if cider
works with those.

[-- Attachment #2: Type: text/html, Size: 1550 bytes --]

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

2016-05-30 13:55 GMT+02:00 Catonano <catonano@gmail.com>:

> 2016-05-30 12:14 GMT+02:00 Alex Kost <alezost@gmail.com>:
>
>>
>> <cough>, OK, I wanted to write verbosely why I prefer
>> uncompressed-file-fetch, and why we should still use it, etc.;
>>
>> but I've just noticed an unpleasant downside with
>> ‘uncompressed-file-fetch’: for example, if you build the recently added
>> "emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
>> impossible to do (require 'queue).  With David's solution, it will be a
>> proper "queue.el" file.
>>
>> So I agree now.  David's patch is definitely a better solution :-)
>>
>>
> Ah ! This is probably why I couldn't manage emacs-cider to require
> emacs-spinner and emacs-queue. They both are packaged with
> uncompressed-file-fetch.
>
> In fact queue and spinner work if I installl them on their own.
>
> After I attempt with cider, they not only are not requirable but they are
> also not autoloaded anymore.
>
> So now I'll try stick with more tested download methods and see if cider
> works with those.
>
>

queue is available only as an uncompresse file

So I'll wait for this patch to be merged and then I'll try with the new
emacs-build-system

[-- Attachment #2: Type: text/html, Size: 2133 bytes --]

Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Thompson, David]

On Mon, May 30, 2016 at 6:14 AM, Alex Kost <alezost@gmail.com> wrote:
> Ludovic Courtès (2016-05-30 00:50 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
>>
>>> Ludovic Courtès (2016-05-28 18:36 +0300) wrote:
>>>
>>>> David Thompson <dthompson2@worcester.edu> skribis:
>>>>
>>>>> * guix/build/emacs-build-system.scm (gnu:unpack)
>>>>> (store-file->elisp-source-file, unpack): New procedures.
>>>>> (%standard-phases): Use the new unpack procedure.
>>>>
>>>> Good idea, LGTM!
>>>>
>>>> Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
>>>> commit, and remove ‘uncompressed-file-fetch’?
>>>
>>> I object!
>>
>> Damn it, sorry, I thought this would be uncontroversial.
>>
>>> I mean this should be discussed at least.  I would really prefer to
>>> keep (and document) 'uncompressed-file-fetch' and not to update
>>> emacs-build-system for this case.  It is possible, that once we'll
>>> need to handle non-compressed files for another build system.  So it
>>> should also be adjusted in the same way.  But if we keep
>>> 'uncompressed-file-fetch', it will be a general decision as it can be
>>> used for any build system.
>>
>> In my view, ‘uncompressed-file-fetch’ and the ‘emacs-build-system’
>> change that Dave proposes are equally good hacks, but the latter has the
>> advantage that people won’t have to think about it: they can just use
>> ‘url-fetch’ and ‘emacs-build-system’ as usual and things will just work.
>>
>> Of course, perhaps we should consider handling flat files closer to the
>> core, but so far the only use case we have, AFAIK, is .el files.  Thus,
>> it doesn’t seem that bad to add a special case in ‘emacs-build-system’.
>> Pragmatic approach I suppose.  ;-)
>>
>> WDYT?
>
> <cough>, OK, I wanted to write verbosely why I prefer
> uncompressed-file-fetch, and why we should still use it, etc.;
>
> but I've just noticed an unpleasant downside with
> ‘uncompressed-file-fetch’: for example, if you build the recently added
> "emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
> impossible to do (require 'queue).  With David's solution, it will be a
> proper "queue.el" file.
>
> So I agree now.  David's patch is definitely a better solution :-)

Hehe.  Thanks for the discussion.  Pushed!

- Dave

Solving the ‘package-name->name+version’ name conflict. (was: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.)

[Mathieu Lirzin]

Hi,

I am a bit late.

David Thompson <dthompson2@worcester.edu> writes:

> * guix/build/emacs-build-system.scm (gnu:unpack)
> (store-file->elisp-source-file, unpack): New procedures.
> (%standard-phases): Use the new unpack procedure.
> ---
>  guix/build/emacs-build-system.scm | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>
> diff --git a/guix/build/emacs-build-system.scm b/guix/build/emacs-build-system.scm
> index f0a9a6e..4fd36d1 100644
> --- a/guix/build/emacs-build-system.scm
> +++ b/guix/build/emacs-build-system.scm
> @@ -21,6 +21,7 @@
>    #:use-module (guix build utils)
>    #:use-module (guix build emacs-utils)
>    #:use-module (srfi srfi-1)
> +  #:use-module (srfi srfi-11)
>    #:use-module (srfi srfi-26)
>    #:use-module (ice-9 rdelim)
>    #:use-module (ice-9 regex)
> @@ -39,6 +40,27 @@
>  ;; archive signature.
>  (define %install-suffix "/share/emacs/site-lisp/guix.d")
>  
> +(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
> +
> +(define (store-file->elisp-source-file file)
> +  "Convert file, a store file name for an Emacs Lisp source file, into a file
> +name that has been stripped of the hash and version number."
> +  (let-values (((name version)
> +                (package-name->name+version
                    ^^^

This is the old ‘package-name->name+version’ from (guix build utils)
which has been replaced when possible by a new one in (guix utils) using
'@' as a delimiter.  While I think it was OK to use it to fix previously
written code, I don't want Guix to build upon the old one.

Time has come to resolve this ugly and confusing name conflict.  The
problem is that I don't fully understand the rationale behind this
temporary solution, so I can't help much.

Ludo: Since you are the mind behind it, I think you are in the best
position to figure this out or at least explain to us “mere mortals”
what is possible and what is not.  :)

-- 
Mathieu Lirzin

Re: Solving the ‘package-name->name+version’ name conflict.

[Ludovic Courtès]

Mathieu Lirzin <mthl@gnu.org> skribis:

> David Thompson <dthompson2@worcester.edu> writes:
>
>> * guix/build/emacs-build-system.scm (gnu:unpack)
>> (store-file->elisp-source-file, unpack): New procedures.
>> (%standard-phases): Use the new unpack procedure.
>> ---
>>  guix/build/emacs-build-system.scm | 23 +++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/guix/build/emacs-build-system.scm b/guix/build/emacs-build-system.scm
>> index f0a9a6e..4fd36d1 100644
>> --- a/guix/build/emacs-build-system.scm
>> +++ b/guix/build/emacs-build-system.scm
>> @@ -21,6 +21,7 @@
>>    #:use-module (guix build utils)
>>    #:use-module (guix build emacs-utils)
>>    #:use-module (srfi srfi-1)
>> +  #:use-module (srfi srfi-11)
>>    #:use-module (srfi srfi-26)
>>    #:use-module (ice-9 rdelim)
>>    #:use-module (ice-9 regex)
>> @@ -39,6 +40,27 @@
>>  ;; archive signature.
>>  (define %install-suffix "/share/emacs/site-lisp/guix.d")
>>  
>> +(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
>> +
>> +(define (store-file->elisp-source-file file)
>> +  "Convert file, a store file name for an Emacs Lisp source file, into a file
>> +name that has been stripped of the hash and version number."
>> +  (let-values (((name version)
>> +                (package-name->name+version
>                     ^^^
>
> This is the old ‘package-name->name+version’ from (guix build utils)
> which has been replaced when possible by a new one in (guix utils) using
> '@' as a delimiter.  While I think it was OK to use it to fix previously
> written code, I don't want Guix to build upon the old one.

We kept this procedure in (guix build utils) because it’s still used.
In this case, we have “foo-1.2”, and we want to get the values “foo” and
“1.2”, so using this procedure is the right thing to do.

> Time has come to resolve this ugly and confusing name conflict.  The
> problem is that I don't fully understand the rationale behind this
> temporary solution, so I can't help much.
>
> Ludo: Since you are the mind behind it, I think you are in the best
> position to figure this out or at least explain to us “mere mortals”
> what is possible and what is not.  :)

Naming is one of the hardest problems in programming, you know!  :-)

So we have:

  (guix build utils):package-name->name+version
    which expects “foo-1.2”

  (guix utils):package-name->name+version
    which expects “foo@1.2”

There’s no doubt we need to keep both, so what we can do is rename one
of them.

What about renaming the one in (guix utils) to
‘package-specification->name+version’?

Bonus points if you provide a patch!  :-)

Thanks,
Ludo’.