From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sebastian Wiesner Newsgroups: gmane.emacs.devel Subject: Re: MELPA version numbers Date: Fri, 2 Aug 2013 17:24:16 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1375475221 16073 80.91.229.3 (2 Aug 2013 20:27:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Aug 2013 20:27:01 +0000 (UTC) Cc: Steve Purcell , Donald Curtis , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 02 22:27:03 2013 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 1V5LwE-00016e-88 for ged-emacs-devel@m.gmane.org; Fri, 02 Aug 2013 22:27:02 +0200 Original-Received: from localhost ([::1]:49854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5LwD-00005N-Pz for ged-emacs-devel@m.gmane.org; Fri, 02 Aug 2013 16:27:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5LwA-00005D-IE for emacs-devel@gnu.org; Fri, 02 Aug 2013 16:27:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5HDN-0004xL-5K for emacs-devel@gnu.org; Fri, 02 Aug 2013 11:24:29 -0400 Original-Received: from mail-qa0-x22f.google.com ([2607:f8b0:400d:c00::22f]:41999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5HDM-0004vx-I7 for emacs-devel@gnu.org; Fri, 02 Aug 2013 11:24:24 -0400 Original-Received: by mail-qa0-f47.google.com with SMTP id o19so380899qap.6 for ; Fri, 02 Aug 2013 08:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QMiKIFQKPYH5DL8lpHE9KbrISJQqAvz1GmFg2URuaRA=; b=tkvKl5CrS0aj6j2uiIwMU8o4QTlvtL1payslskot7edHw/ZAMnrrykwXjIKgZJI16y 5d5ZJO7TUllLGfoU9lry5JMo2FPR42+FpK8W/PjZMGmA+tIfBnxB09WKX7F2SJBUnuOq qSBC+oLBsaKtwrZEjdyG2+ivBvtGGeT/64MHnjpCINbFbwT/7t8KIcM9U/SogvcC0r5q mYAH9v6FCe9wZvcwVHkNCFkf801YLSTiQe9tVoB/yHfoHt9erCAtLjB2JYd3PN1pPpVE 4+tFn61eJOTYejwOXySqS8cFHBJodmhjvVHqRpMC7kI7Zs4WdZuklviISk1/yOZN0VFM CgrA== X-Received: by 10.224.4.202 with SMTP id 10mr12354727qas.1.1375457056233; Fri, 02 Aug 2013 08:24:16 -0700 (PDT) Original-Received: by 10.224.21.136 with HTTP; Fri, 2 Aug 2013 08:24:16 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c00::22f 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:162392 Archived-At: 2013/8/2 Stefan Monnier : >> It doesn't track archives independently, and though it actually stores >> the origin of a package, it doesn't make any use of this information >> at all. > > Not true any more. When you click on a package, it lists the "other > versions" it knows about, including their respective origin. > > Also you can pin a package to a particular archive. Indeed, I just discovered "package-pinned-packages", which I presume is what you are referring to. In theory it's a nice feature, but I really dislike the current implementation. I am actually a bit disappointed about the quick hack that was use to implement this feature: When reading the package archives, package.el appears to just ignore(!) all package versions which are pinned to another archive. It'll not just put them in a different list, or track them somewhere else, no, it will completely forget that these package versions even existed! I can't say that I like this, I am actually quite disappointed about this quick and dirty hack to implement pinning. Essentially, "package-archive-contents" doesn't reflect the actual archive contents anymore, but rather package archives minus some random, possibly broken user configuration. Essentially package-archive-contents is not at all reliable anymore, which opens up for a wide range of hard to debug errors. For instance, assume the user accidentally pins a package Foo to a non-existing archive, e.g. by a spelling mistake or whatever. Package.el hence discards all versions of this package when reading the contents, so that "package-archive-contents" does not even contain Foo. Not because it does exist, no, but just because of a user error. If the user later attempts to install a package Bar which requires Foo, she'll be confronted with a plain and completely "package Foo is not available" message. Even if it wanted to, package.el could not warn the user, simply because package.el itself doesn't know about Foo anymore. Ideally, pinning would be evaluated when installing a package. In this case, package.el could easily detect the above misconfiguration by looking at "package-archive-contents", and warn about package Bar being available, but pinned to another archive. It could even warn about packages being pinned to non-existing archives. Please revise the implementation of this feature, and do *not* drop pinned packages from "package-archive-contents". >> These limitations sort of defeat the purpose of having >> multiple archives imho. > >> Ideally, package.el would track *all* packages of *all* repositories >> in "package-archive-contents" (not just the latest out of all >> repositories), so that packages, which are contained in multiple >> archives, also appear multiple times in M-x list-packages, once for >> each archive. > > The current package.el does store all packages in > package-archive-contents, IIRC. Indeed, I also just discovered it. With the exception of the bad pinning implementation, this is really nice. We'll hopefully make use of this in Carton soon, probably to implement our own approach to pinning (unless pinning is improved, see above). > And M-x list-packages only has one > entry per package, but once you select one of those entries, it should > tell you about all the versions it knows. > > If you prefer to list all the versions directly in list-packages, we > could add an option for that (patches welcome). I don't care for the UI, I am only concerned about the implementation and API of package.el. I manage my packages through Carton (, and Carton has to >> This more sophisticated way of tracking archives would not only neatly >> solve the problem of MELPA version numbers (without even touching them), > > No, it doesn't really solve the problem: most people wouldn't know when > MELPA's version is out of date. How would you know to switch archive if > package.el doesn't tell you that there's a newer version in the > "gnu" archive? How exactly can that happen given that MELPA *always* builds VCS snapshots, with are *by definition* the most recent state of a package? Or, in other words, if a GNU ELPA package happens to be more recent than MELPA, that's a failure in MELPA, because it's the explicit aim of MELPA to always provide the most recent snapshots of any included package.