From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Thu, 5 Nov 2015 05:00:30 +0200 Message-ID: <563AC64E.9060105@yandex.ru> References: <563ABD66.6070700@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1446692452 6495 80.91.229.3 (5 Nov 2015 03:00:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 03:00:52 +0000 (UTC) To: emacs-devel@gnu.org, Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 05 04:00:47 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 1ZuAn4-0006Bt-3Q for ged-emacs-devel@m.gmane.org; Thu, 05 Nov 2015 04:00:42 +0100 Original-Received: from localhost ([::1]:58243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuAn3-0008Fx-2p for ged-emacs-devel@m.gmane.org; Wed, 04 Nov 2015 22:00:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuAmx-0008En-RT for emacs-devel@gnu.org; Wed, 04 Nov 2015 22:00:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuAmv-00056Q-1s for emacs-devel@gnu.org; Wed, 04 Nov 2015 22:00:35 -0500 Original-Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:33989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuAmu-00056L-Og for emacs-devel@gnu.org; Wed, 04 Nov 2015 22:00:32 -0500 Original-Received: by wmnn186 with SMTP id n186so2597499wmn.1 for ; Wed, 04 Nov 2015 19:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=7M1yHZLJJ5Czv7dl6qEgYMo6sSKqiEzyr5m0EOsPKjc=; b=z2yuNZlo9sRXhuNjVe/DysVz/54jYk2DFSCDaXtLBG65zM/Z4AyM9GNkqIZwa17ikU IWHRB8JPhkwDC7r2ZJYY6WT2T+HJYArjAKXhete3Rp7djZlFvGO5C14jDvaKC/2vSnqd VtfwLxtvRM0cJJZohoAHeTbUSdx+R5DM8yzANXW4hW8PbOxy/TT1ykufTZrcCTuzEBt/ XCi6PRNxju6Sw4W6zLYpyPXYZLDw09qhJZjlD46yZrAe5qbGq/6RVvWRVozdZQKvTVA+ I/efXOQY4EisoH3q0s7wWQ1e8v55puVRDbe6Z3JVZAQWOKa5UGoM65ZRxzMe9l8cVn7L RGZw== X-Received: by 10.28.137.211 with SMTP id l202mr530662wmd.90.1446692432139; Wed, 04 Nov 2015 19:00:32 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id ju5sm4522317wjc.1.2015.11.04.19.00.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 19:00:31 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22a 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:193265 Archived-At: On 11/05/2015 04:41 AM, John Wiegley wrote: > An exception to this rule is when a certain service (say, streams) should > always be available, without requiring further installation of libraries. > Emacs acts as a sort of "standard library" for Emacs Lisp, so the same kinds > of things we'd like to have in such a meta-library, should be in core. Why not consider ELPA a part of the "standard library", too? As long as all code that uses streams.el is not in Emacs core, I don't see any harm in requiring the user to install streams from ELPA (which would probably happen automatically, via a declared dependency). When the core starts using it, sure, we can move it there. > I do think that applications using such libraries should almost always go in > ELPA, except for those that have been grandfathered in, like Emacs Calc. There > are some things you should always be able to reach for, no matter whose > machine you are on, or if the Internet is currently available. Yes, some pieces of functionality that we consider a part of the standard set (Calc is not that, for me, but apparently it's popular enough). The criteria for applications to include them might be that Emacs has dedicated menu items, or uses the application's commands in some global bindings (that's why xref, for example, can't be moved to ELPA).