From: ludo@gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Solving the ‘package-name->name+version’ name conflict.
Date: Wed, 08 Jun 2016 14:44:01 +0200 [thread overview]
Message-ID: <87eg87kfzi.fsf@gnu.org> (raw)
In-Reply-To: <87vb1vmrye.fsf@gnu.org> (Mathieu Lirzin's message of "Mon, 30 May 2016 18:27:37 +0200")
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’.
prev parent reply other threads:[~2016-06-08 12:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 14:10 [PATCH 1/2] build: emacs: Handle sources that are a single elisp file David Thompson
2016-05-27 14:10 ` [PATCH 2/2] gnu: Add emacs-better-defaults David Thompson
2016-05-28 14:05 ` Alex Kost
2016-05-28 15:37 ` Ludovic Courtès
2016-05-30 15:11 ` Thompson, David
2016-05-31 16:59 ` Mark H Weaver
2016-05-31 17:16 ` Thompson, David
2016-06-01 2:07 ` Mark H Weaver
2016-05-31 20:53 ` Alex Kost
2016-05-31 20:55 ` Thompson, David
2016-05-28 13:59 ` [PATCH 1/2] build: emacs: Handle sources that are a single elisp file Alex Kost
2016-05-28 15:36 ` Ludovic Courtès
2016-05-28 19:05 ` Alex Kost
2016-05-29 21:50 ` Ludovic Courtès
2016-05-30 10:14 ` Alex Kost
2016-05-30 11:55 ` Catonano
2016-05-30 12:42 ` Catonano
2016-05-30 15:12 ` Thompson, David
2016-05-30 16:27 ` Solving the ‘package-name->name+version’ name conflict. (was: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.) Mathieu Lirzin
2016-06-08 12:44 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eg87kfzi.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=mthl@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.