emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature/integrated-elpa 4f6df43 15/23: README added


From: Andy Moreton
Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added
Date: Fri, 14 Oct 2016 14:51:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt)

On Fri 14 Oct 2016, Eli Zaretskii wrote:

>> From: address@hidden (Phillip Lord)
>> Cc: Eli Zaretskii <address@hidden>,  <address@hidden>,  <address@hidden>
>> Date: Fri, 14 Oct 2016 09:20:14 +0100
>> 
>> > Do you really want to give up this standard file structure?
>> 
>> 
>> Yes, because it is not standard. It's one of two standards.
>> 
>> If you install org with package.el, then you get
>> 
>> ~/.emacs.d/elpa/org/org
>> ~/.emacs.d/elpa/org/etc/ORG-NEWS
>> ~/.emacs.d/elpa/org/org.el
>> 
>> So, org-mode has to support two independent directory layouts.
>
> But Org already supports those two formats.  We don't require Org to
> do anything that it doesn't already do.  So staying with the current
> structure of lisp/ in the Emacs tree doesn't add any new requirements.

But that would do nothing to reduce the unnecessary and duplicated
packaging work.

Keeping each package in ELPA format ensures that replacing the package
can be done easily, as everything is isolated in a single directory. If
the package is shipped in the emacs tarball and the user then upgrades
to a newer version from ELPA, only the load path needs to change.

In additon, the user can easily compare the changes bewteen the package
version shipped in the emacs tarball and the updated one fetched from
ELPA, as the package layout is the same.

There are many more users of emacs than developers, so the design
should be aimed at utility and convenience for users.

    AndyM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]