From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Thu, 12 Nov 2015 13:52:00 -0600 Message-ID: <86pozfc7xb.fsf@stephe-leake.org> References: <87ziyuaqhl.fsf@petton.fr> <83twovm9es.fsf@gnu.org> <868u65afvh.fsf@stephe-leake.org> <87lha5snji.fsf@isaac.fritz.box> <87d1vhsmuj.fsf@isaac.fritz.box> <878u65slue.fsf@isaac.fritz.box> <874mgtsjwn.fsf@isaac.fritz.box> <867flp8nb7.fsf@stephe-leake.org> <9e33129a-07d0-4abe-a94e-32d6d881519b@default> <86bnb06g7g.fsf@stephe-leake.org> <861tbwcju9.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447358079 15916 80.91.229.3 (12 Nov 2015 19:54:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 19:54:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Filipp Gunbin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 20:54:28 2015 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 1Zwxwy-0005ZW-Gw for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 20:54:28 +0100 Original-Received: from localhost ([::1]:49515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwxwx-0006DD-PZ for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 14:54:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwxuo-0002YN-81 for emacs-devel@gnu.org; Thu, 12 Nov 2015 14:52:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwxul-0002PF-H6 for emacs-devel@gnu.org; Thu, 12 Nov 2015 14:52:14 -0500 Original-Received: from gproxy9-pub.mail.unifiedlayer.com ([69.89.20.122]:43170) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Zwxul-0002P6-Ae for emacs-devel@gnu.org; Thu, 12 Nov 2015 14:52:11 -0500 Original-Received: (qmail 32205 invoked by uid 0); 12 Nov 2015 19:52:07 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 12 Nov 2015 19:52:07 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id gqs11r0132UdiVW01qs4QK; Thu, 12 Nov 2015 19:52:04 -0700 X-Authority-Analysis: v=2.1 cv=Caqbutbl c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=F-6IPfh70HgjRjUjNSgA:9 Original-Received: from [76.218.37.33] (port=56411 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zwxud-0002aj-Sy; Thu, 12 Nov 2015 12:52:04 -0700 In-Reply-To: (Filipp Gunbin's message of "Thu, 12 Nov 2015 16:24:24 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.20.122 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:194278 Archived-At: Filipp Gunbin writes: > Stephen, > > On 11/11/2015 15:22 -0600, Stephen Leake wrote: > >>> If sufficient amount of important packages use some API and that API >>> is rather mature, then the maintainer can decide to move that in core >>> to simplify dependency management. >> >> or to a tarball ELPA package, or to a core ELPA package. >> >> Perhaps that is too much choice? > > Mm yes, that's one of my fears, that it will become too complex for a > package maintaner. Why not just treat each ELPA package just as an ELPA > package and leave the option of bundling it to core maintainers which > are better in this area (they'll do it in agreement with package > maintainer, of course)? > > A "tarball" ELPA package is a one thing (that's what I call "bundle into > tarball", if I understood right), Yes. We have not implemented this yet, but I'm imagining there is a list of these in the Gnu Emacs Makefile somewhere (probably in a separate file read by the Makefile). I don't think there will need to be any metadata in the package files for this. Declaring an ELPA package to be a tarball package does impose some restrictions on the package maintainer; they have to synchronize with each Emacs release, and accept the same review/oversight as core code. > but "core" ELPA package is another - > here I have another fear, that normal and tarball ELPA packages > depending on such "core" packages, will have to accurately define > versions of the core package they support, and then we have to check all > this during the installation. I don't see why that is different from depending on a normal ELPA package. > We'll probably have to calculate and offer to user which set of the > multiple core packages' multiple versions suits for multiple normal > and tarball (perhaps overriden by version from Internet package > archive) packages, at the same time probably giving the user to > opportunity to specify her preferred version of each requested > package. Is it worth the trouble? Or do I understand something wrong? Emacs does not support multiple versions of packages available simultaneously; there is only one instance of a package that is first in load-path. You can end up with one copy in the installed Emacs distribution, and one in ~/.emacs.d/elpa. But the elpa one will take precedence; that is the only one that other packages have to worry about. It either meets their dependency requirement, or not. > That's why I wrote about the feature latency - maybe it would be enough > if a person willing to use latest core features in her package will have > to develop it on git emacs and wait for the next official release to > make her package available to the public. This will be the same as with > new C level features, which we cannot "push quicky" as we can with ELPA > package. That's the main reason to make a package available in both core and ELPA: users of the released version of Emacs can use the latest version of the core ELPA package from ELPA, overriding the copy in their installation. >>> So, I'd suggest that: >>> >>> - Language features go straight into core (and people working on them >>> / using them will have to use git version of Emacs until next >>> release) > > No-no, what I meant were Emacs Lisp libraries extending language, like > seq.el. That's a good candidate for a core ELPA package. -- -- Stephe