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: Fri, 13 Nov 2015 16:06:03 +0300 Message-ID: References: <87ziyuaqhl.fsf@petton.fr> <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> <86pozfc7xb.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447419990 23260 80.91.229.3 (13 Nov 2015 13:06:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 13:06:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 13 14:06:19 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 1ZxE3V-0000A7-TI for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 14:06:18 +0100 Original-Received: from localhost ([::1]:52905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxE3V-0001WX-Kj for ged-emacs-devel@m.gmane.org; Fri, 13 Nov 2015 08:06:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxE3Q-0001W3-7s for emacs-devel@gnu.org; Fri, 13 Nov 2015 08:06:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxE3M-0006Kb-SG for emacs-devel@gnu.org; Fri, 13 Nov 2015 08:06:12 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:46669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxE3M-0006KT-Jr for emacs-devel@gnu.org; Fri, 13 Nov 2015 08:06:08 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ECA9A20CDA for ; Fri, 13 Nov 2015 08:06:07 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 13 Nov 2015 08:06:07 -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=vraRu gYudPhudrED/qgcvofFcyc=; b=Ajky8IUYFU5As9O/19nRB8M345v+FbsTmbnzI jH9N5nPgpdQEvEtVFHwdVU3qlSbSql1uqy/7sV4e00yF7XCHPlBaWNNRmPnMGkqH wqYstnnxCsgFoKF1bg+hMJFeyrHBCfvS1nCv96Y6jj5Epkhhwj6hCuSEI6xKdtNC hLq4SY= 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=vraRugYudPhudrED/qgcvofFcyc=; b=Sp+Nh +A9nL+mrpjHYrfBJA+J0kvBxhVfO94GsOfrLqQ2c7LX5Z12+Rda4tzh+kDnJqp+E MHTiyVTQTlQgFIC+MSSmePBFkuUtKk3ZFY8ZyupR1rgnLxm9KBQKtFZrRzIczMgA TybOyUMRE/b3Hd2MIr/dkvCofGDIG6cSu9+pwU= X-Sasl-enc: DWjBHxiRekqQkJb3/0rR8ZR7CpqX/lyvW1qVOEwhUTds 1447419967 Original-Received: from fgunbin.local (unknown [94.25.218.10]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A13968012B; Fri, 13 Nov 2015 08:06:07 -0500 (EST) In-Reply-To: <86pozfc7xb.fsf@stephe-leake.org> (Stephen Leake's message of "Thu, 12 Nov 2015 13:52:00 -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:194355 Archived-At: On 12/11/2015 13:52 -0600, Stephen Leake wrote: >> 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. They'll just have to make sure that a single version (which is going to be bundled in a tarball) works good with an Emacs release being prepared. >> 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. I think it's their dependants what make them different from tarball and normal packages. Emacs core provides API, which others use. A normal package declares which versions of this API it is supposed to work against. With core packages, Emacs still provides API, but it now consists of a static part (C level & core) and dynamic part (core packages, which can later be updated from ELPA - correct me if I'm wrong). So, a package should independently define which core version it works agains and which core package(s) version(s) it works against. Here's where I see the complexity with multiple packages installed on user request with package manager, which I tried to describe below. >> 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. Of course, I was talking about the set of available versions which could be installed and from which a user or a package manager should choose. >> 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. Yes, but it can introduce complexities I wrote of above. Filipp