all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Federico Beffa <beffa@ieee.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: emacs packages
Date: Tue, 23 Jun 2015 08:48:40 +0200	[thread overview]
Message-ID: <CAKrPhPOtL7RL0e4ZXidfjF7Ps0VFmjaj97Q4f+J9wZ7=pUB+Dw@mail.gmail.com> (raw)
In-Reply-To: <87pp4n8r6e.fsf@gnu.org>

On Mon, Jun 22, 2015 at 9:43 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> On Sun, Jun 21, 2015 at 11:12 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>
> [...]
>
>>>>>> Unfortunately this doesn't work without modification. The reason is
>>>>>> that I follow the emacs package.el strategy to install each ELPA
>>>>>> package in it's own sub-directory. Specifically, I'm installing each
>>>>>> package into ".../site-lisp/guix.d/PACKAGE-NAME-VERSION/".  The code
>>>>>> in 'guix.el', however, doesn't look in sub-directories below the
>>>>>> profile's '.../site-lisp'.
>
> [...]
>
>>>> the reason for using separate sub-directories is that many packages
>>>> include files, such as README, ChangeLog, ..., that are likely to
>>>> clash. Even if we would delete all non ".el" files (which probably is
>>>> not safe), with more than 2500 packages on MELPA, it is possible that
>>>> we would still experience some name clashes. I can imagine that
>>>> someone preparing a package may be unaware of the existence of some
>>>> other package, possibly not very popular in his circle.
>>>
>>> What about copying all the .el files to .../site-lisp, and copy the
>>> other files elsewhere (for instance, ‘README’ and ‘ChangeLog’ to
>>> share/doc/$PACKAGE, and .info files to share/info)?
>>
>> I am copying .info files to share/info.
>
> Ah OK, perfect then!
>
>> I'm not copying README files to share/doc because these usually do not
>> provide useful documentation for the user and ChangeLog are usually
>> not up-to-date relict. But if somebody feels strongly about it, I can
>> change that.
>
> No, that’s fine.
>
>>> Note that name clashes in profiles are annoying, but not fatal.
>>
>> For .el files they are.
>
> They are fatal but rare, no?  My impression is that people prefix their
> .el file names with the package name.  In my profile I have emms, bbdb,
> emacs-w3m, magit & deps, geiser, cflow, etc. and there are zero clashes.
> I don’t see any clash in the dozen of packages I still have in
> ~/.emacs.d/elpa/ either.
>
>> I also do not think that it is very sane ending up with a flat
>> directory including hundreds of files. Some hierarchy makes the
>> organization much more apparent and clean.
>
> The problem is that, unlike Guile modules, elisp module names are
> inherently flat, hence the PACKAGE-foo.el convention that people seem to
> follow.
>
> But perhaps that convention is not strictly followed, which would
> explain why package.el took this route?
>
> I don’t feel strongly against what you suggest.  My main concern would
> be the introduction of extra complexity that’s not strictly needed, but
> you seem to be saying that it *is* needed.

I'm just saying: If we use separate directories as package.el does, we
avoid all name clashes with probability 1. If we use a flat structure
such a claim can not be done.

Even if the clash "only" happens with, say, a README file, the state
of the system (user profile) would depend on the order of
installation. To me that is very bad, especially if there is an easy
solution to prevent that as in this case.

>
> Regardless, what matters most to me is that guix.el and
> ‘emacs-build-system’ work consistently.

I fully agree and Alex last Friday already posted a small patch to
make guix.el look into sub-directories.

https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00382.html

Regards,
Fede

  reply	other threads:[~2015-06-23  6:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15 10:20 emacs packages Federico Beffa
2015-06-15 10:45 ` Mathieu Lirzin
2015-06-16 16:00 ` Ludovic Courtès
2015-06-16 16:21   ` Pjotr Prins
2015-06-17  7:42   ` Federico Beffa
2015-06-17 18:21     ` Alex Kost
2015-06-18 18:32       ` Federico Beffa
2015-06-19  9:56         ` Alex Kost
2015-06-19 12:13     ` Ludovic Courtès
2015-06-19 16:06       ` Federico Beffa
2015-06-21 21:12         ` Ludovic Courtès
2015-06-22  7:30           ` Federico Beffa
2015-06-22 19:43             ` Ludovic Courtès
2015-06-23  6:48               ` Federico Beffa [this message]
2015-06-23 12:47                 ` Ludovic Courtès
2015-06-16 16:24 ` Mark H Weaver
2015-06-16 19:31   ` Federico Beffa
2015-06-17 18:42     ` Mark H Weaver
2015-06-17 20:00       ` Alex Kost
2015-06-18 18:24         ` Federico Beffa

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='CAKrPhPOtL7RL0e4ZXidfjF7Ps0VFmjaj97Q4f+J9wZ7=pUB+Dw@mail.gmail.com' \
    --to=beffa@ieee.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@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.