From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jonathan Leech-Pepin Newsgroups: gmane.emacs.devel Subject: Re: Bundling GNU ELPA packages Date: Thu, 6 Nov 2014 14:43:12 -0500 Message-ID: References: <878ujowbnh.fsf@thinkpad-t440p.tsdh.org> <87sihwm8jj.fsf@thinkpad-t440p.tsdh.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134c51858fe0b050735e9ea X-Trace: ger.gmane.org 1415303027 4891 80.91.229.3 (6 Nov 2014 19:43:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Nov 2014 19:43:47 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 06 20:43:40 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XmSy4-0000IQ-Fh for ged-emacs-devel@m.gmane.org; Thu, 06 Nov 2014 20:43:40 +0100 Original-Received: from localhost ([::1]:55774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmSy3-00088f-Ty for ged-emacs-devel@m.gmane.org; Thu, 06 Nov 2014 14:43:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmSxz-00088X-CU for emacs-devel@gnu.org; Thu, 06 Nov 2014 14:43:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmSxy-0001EW-2y for emacs-devel@gnu.org; Thu, 06 Nov 2014 14:43:35 -0500 Original-Received: from mail-qc0-x235.google.com ([2607:f8b0:400d:c01::235]:38041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmSxx-0001EF-TS for emacs-devel@gnu.org; Thu, 06 Nov 2014 14:43:34 -0500 Original-Received: by mail-qc0-f181.google.com with SMTP id w7so1366734qcr.40 for ; Thu, 06 Nov 2014 11:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=XFAXnRpHbba5+82+5kPcAOPfZNuHV8MBd1HGAGZIeYY=; b=R3C/gDCZZvFO7IAil5sLy+RGmi33BljbCmUfC0hn63iCW6FZ9HW/dOxZ/UMjTp3BoG +WBcMzK7O6q2T6l15Xl+G2kFUpZoeWOczwHgCjetrhC/dbfsaLci+Fw7kJbYZl5dp9vs MRA/ehwSBj6ejDsSyjoUm6Ljs6TSl1P7nGwLxVWWYLNCRqbHaaoYNLG3IPHEbbbNpxmy 1lLdNjCJUm1Up1eMlfqrEtAU65l5Bxdo/VPoNg9Q+luwOv2fAY9qdRPa6bv4PxbFqXHX 8dVVzhg7XRQZvmc4vYgYw9t/42UKyabTtyc81VtSLGFSzlyMyd5etPQhREaAS/CE5/Qn 3XbQ== X-Received: by 10.229.216.1 with SMTP id hg1mr10270994qcb.15.1415303013136; Thu, 06 Nov 2014 11:43:33 -0800 (PST) Original-Received: by 10.96.48.4 with HTTP; Thu, 6 Nov 2014 11:43:12 -0800 (PST) In-Reply-To: <87sihwm8jj.fsf@thinkpad-t440p.tsdh.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c01::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176476 Archived-At: --001a1134c51858fe0b050735e9ea Content-Type: text/plain; charset=UTF-8 On 6 November 2014 14:30, Tassilo Horn wrote: > Stefan Monnier 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 > > --001a1134c51858fe0b050735e9ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 6 November 2014 14:30, Tassilo Horn <tsdh@gnu.org> wrote:<= br>
Stefan Monnier <monnier@iro.umontreal.ca> wri= tes:
[...]
> 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.=C2=A0 I understand all those points.=C2=A0 What I= don't
understand is why we don't move org, gnus, and other built-in packages<= br> which aren't "super-core" (i.e., not everybody needs them) fr= om
emacs.git to elpa.git?=C2=A0 Then all points above still apply, and emacs releases are a bit more lightweight.=C2=A0 I mean, for fast-evolving packag= es
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.=C2=A0 But that can be documented easily:

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

=C2=A0 =C2=A0 1. emacs -Q
=C2=A0 =C2=A0 2. M-x package-install RET org RET
=C2=A0 =C2=A0 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 functio= ns 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.=C2=A0 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 p= roceed, otherwise prompt the user.

Regards,
Jonathan
---
=C2=A0
Bye,
Tassilo


--001a1134c51858fe0b050735e9ea--