emacs-devel
[Top][All Lists]
Advanced

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

Re: Bundling GNU ELPA packages


From: Jonathan Leech-Pepin
Subject: Re: Bundling GNU ELPA packages
Date: Thu, 6 Nov 2014 14:43:12 -0500



On 6 November 2014 14:30, Tassilo Horn <address@hidden> wrote:
Stefan Monnier <address@hidden> writes:
[...]

> Having a package in ELPA means that it can be updated independently
> from Emacs.
>
> Having packages in elpa.git instead of emacs.git makes their release
> schedules independent.
>
> Having bundled packages in both emacs.git and in elpa.git means
> 2 branches to keep in sync.

Yes, yes, and yes.  I understand all those points.  What I don't
understand is why we don't move org, gnus, and other built-in packages
which aren't "super-core" (i.e., not everybody needs them) from
emacs.git to elpa.git?  Then all points above still apply, and emacs
releases are a bit more lightweight.  I mean, for fast-evolving packages
like org and company, if emacs 25.1 bundles version X, the next day
version X+1 is available from ELPA anyway.

The only downside I can see is that users upgrading from Emacs 24 to 25
might get startup errors because formerly built-in packages aren't
anymore.  But that can be documented easily:

  If you used the built-in org-mode version in Emacs < 25, do

    1. emacs -Q
    2. M-x package-install RET org RET
    3. Now you can restart emacs without -Q

Or even better, there could be some hack that when emacs 25.1 is started
the first time puts the user in a package manager tutorial that guides
him thru the process of installing packages with an emphasis on formerly
built-in packages.

Or even (assuming this is feasible):

1. Define a set of 'partial-core' packages (e.g Gnus, Org, CEDET) that have autoloads* defined.
2. When the functions are called, advise that the package is not yet installed and prompt the user to install it
3. Prompt user to restart Emacs (Assuming it is required if the package was not previously present in that version

* Autoloads is perhaps the wrong term.  More something akin to disabled-commands where it attempts to require the package, if the package is found (installed to load path from site-lisp or locally) then proceed, otherwise prompt the user.

Regards,
Jonathan
---
 
Bye,
Tassilo



reply via email to

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