From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Filipp Gunbin Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Thu, 12 Nov 2015 16:24:24 +0300 Message-ID: References: <87ziyuaqhl.fsf@petton.fr> <5640C6A0.5010709@yandex.ru> <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 1447334720 20145 80.91.229.3 (12 Nov 2015 13:25:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 13:25:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 14:25:07 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 1Zwrrr-0003TP-2P for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 14:24:47 +0100 Original-Received: from localhost ([::1]:46635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwrrq-00042Y-EZ for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 08:24:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwrra-00042R-Kb for emacs-devel@gnu.org; Thu, 12 Nov 2015 08:24:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwrrX-0007iS-EL for emacs-devel@gnu.org; Thu, 12 Nov 2015 08:24:30 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwrrX-0007iO-7x for emacs-devel@gnu.org; Thu, 12 Nov 2015 08:24:27 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DF33920856 for ; Thu, 12 Nov 2015 08:24:26 -0500 (EST) Original-Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 12 Nov 2015 08:24:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=puNkD krpVbzm5aaci7wkgz9+3Ic=; b=EXcJr7vgbkz3p6n83wXpK+JmDhh/f6BCEKXsI hMlxpoMqr7sqzbpdKXs8hkFNBsAKsSGhRd+KNzrSEyCKSdxwG0m277AVsL8knpCI EkRPugIUxH9jVC/3J/LZEGIPJ3yt1gJLxG4sGSl6evltWDdJz/zd9hw69hAAoFOO bUhbM0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=puNkDkrpVbzm5aaci7wkgz9+3Ic=; b=FFGuL rXXlKh99W0RCn7DYBrhG+U6Uqp6WinXtmGi/rP2IIDHE4gPNYpkdUH5HfshEF4cV jSUGnrxUec9U3NgU2xdgTzHPQ8pnQ/0Dm1U9wWsSk0SfgR2VKYNa+9/Sb2YvlD07 Xf+GdywGcgWgYoFNS5fnGDd3YyxOndlOihNxGQ= X-Sasl-enc: m1VB3T4elcy5Y5daVxNU5iCzsHvg/0dnpR8L9Pr97UBB 1447334666 Original-Received: from fgunbin.local (unknown [94.25.218.10]) by mail.messagingengine.com (Postfix) with ESMTPA id 29A60C016F2; Thu, 12 Nov 2015 08:24:26 -0500 (EST) In-Reply-To: <861tbwcju9.fsf@stephe-leake.org> (Stephen Leake's message of "Wed, 11 Nov 2015 15:22:22 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.28 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:194223 Archived-At: 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), 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. 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? 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. >> 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) > > By "language features" do you mean things like ada-mode.el (primary mode > for editing Ada source files)? If so, I strongly disagree; ada-mode.el > is very happy as a normal ELPA package. Similar modes for other > languages with a small audience could be in ELPA as well; I have not > looked to see what's actually there. No-no, what I meant were Emacs Lisp libraries extending language, like seq.el. >> The API / SPI notion can also be used to provide implementations >> (backends) for different features which may have default simple >> implementations in core and more advanced ones in packages. A package >> must somehow "register" itself as a candidate for being a service for >> a concrete feature during installation. > > If we use cl-generic to provide dispatching, the cl-defmethod form does > the registration. Thanks, that's one more reason for me to become acquainted with Emacs CL features. Filipp