From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal) Date: Mon, 10 Nov 2014 18:24:21 -0500 Message-ID: References: <87a943umku.fsf@lifelogs.com> <87ppcvm7fj.fsf@newcastle.ac.uk> <87vbmndk46.fsf@lifelogs.com> <87wq72ls2h.fsf@ferrier.me.uk> <87k332lnn3.fsf_-_@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415661907 31098 80.91.229.3 (10 Nov 2014 23:25:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Nov 2014 23:25:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nic Ferrier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 11 00:24:59 2014 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 1XnyKM-0001EM-SU for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2014 00:24:55 +0100 Original-Received: from localhost ([::1]:45508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnyKM-0000gu-Df for ged-emacs-devel@m.gmane.org; Mon, 10 Nov 2014 18:24:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnyK2-0000gj-3r for emacs-devel@gnu.org; Mon, 10 Nov 2014 18:24:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnyJr-0003Ud-LN for emacs-devel@gnu.org; Mon, 10 Nov 2014 18:24:34 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:8609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnyJr-0003UO-IA for emacs-devel@gnu.org; Mon, 10 Nov 2014 18:24:23 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSQKiEEJy3IBAQEHAQEBAR6QMAFXB4RLBYtkjS8FmQiBb4I0gWIfgTUBH4ElAQEB X-IPAS-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSQKiEEJy3IBAQEHAQEBAR6QMAFXB4RLBYtkjS8FmQiBb4I0gWIfgTUBH4ElAQEB X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96597752" Original-Received: from 75-119-235-29.dsl.teksavvy.com (HELO pastel.home) ([75.119.235.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 18:24:22 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id F000F735D; Mon, 10 Nov 2014 18:24:21 -0500 (EST) In-Reply-To: <87k332lnn3.fsf_-_@ferrier.me.uk> (Nic Ferrier's message of "Mon, 10 Nov 2014 22:02:56 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:176727 Archived-At: > I am cross about the way we are building this system, ELPA. Just to avoid confusion in the discussion: ELPA is the name of the general package distribution system, IOW the protocol between package.el and the web servers. There are several servers which follow this protocol, such as Marmalade, MELPA, and GNU ELPA. > Not about package.el, or about what ELPA is. But about how ELPA (and > MELPA) work, and to some extent, the provisions we have made for package > creation. IIUC by "ELPA" above I guess you mean GNU ELPA (since "ELPA and MELPA" would otherwise combine with "and" two things of different nature). > The multi-packages users load in their emacs are tars. But the packages > that are checked in to ELPA are directories of files. ^^^^^^^^^^^^^^^^^^ So I think here you mean elpa.git (part of the greater GNU ELPA). > So package authors are not checking in what gets delivered to the > user. So there is a magic build step somewhere. Indeed. Note that for all packages (even single-file packages) there are yet more build steps elsewhere: - the creation of the -autoloads.el. - the creation of the *.elc files. > This discourages testing of packages before they are distributed. The "magic step" that turns a directory in elpa.git into a tarball is fairly limited currently. It is basically limited to "create -pkg.el then tar". Given the desire to limit the number of external tools required (which is why we distribute *.tar and not *.tar.gz, for example), I think that "tar+untar" is pretty close to the minimum way to transfer a directory of files from the developer's machine to the user who installs the package. Note that there is a fair bit a pressure to *add* rather than remove magic steps (the first candidate in the list is to build the *.info files from the *.texi files). The way to "test" for elpa.git is "cd .../elpa; make" which should create the *-autoloads.el and *-pkg.el and *.elc files in the "same" way as what will happen on the user's machine. > And I am really starting to think we need better testing. 24.4 looked > like a slog to release and it still has many bugs. FWIW, I haven't heard of any case where the issues you're pointing out have resulted in actual problems. The only real reliability problem I've heard about linked to ELPA packages is the issue of compiling/installing a package when an older version is already installed. Stefan