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: cl-defstruct-based package.el, now with ert tests and no external tar! Date: Tue, 25 Jun 2013 19:32:12 +0200 Message-ID: References: <87y5cx0wh7.fsf@yandex.ru> <87ppy7e5ke.fsf@lifelogs.com> <87vc5x1uzj.fsf@yandex.ru> <87txlcdyl1.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372181541 29957 80.91.229.3 (25 Jun 2013 17:32:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 17:32:21 +0000 (UTC) Cc: Dmitry Gutov , Daniel Hackney , Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 25 19:32:22 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 1UrX6L-0007Mz-HQ for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 19:32:21 +0200 Original-Received: from localhost ([::1]:56138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrX6K-0002BB-UE for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 13:32:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrX6F-0002AM-8y for emacs-devel@gnu.org; Tue, 25 Jun 2013 13:32:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrX6D-0001zl-Tj for emacs-devel@gnu.org; Tue, 25 Jun 2013 13:32:15 -0400 Original-Received: from mail-qc0-x236.google.com ([2607:f8b0:400d:c01::236]:55086) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrX6D-0001za-PV for emacs-devel@gnu.org; Tue, 25 Jun 2013 13:32:13 -0400 Original-Received: by mail-qc0-f182.google.com with SMTP id e10so7477195qcy.13 for ; Tue, 25 Jun 2013 10:32:13 -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:content-transfer-encoding; bh=EOJhkuNmy5iyx8S6x/tBAasDn1vFsEpH9IMAVQzAF/c=; b=yFaAHE6TSA3of2jD37UmMKHKJaR81pGzIHaoqTfid6OMGkAemOXSiC4xfcsLls6Z5c odykuVAiL77XtEzRjjiTnPvZnCZzT48FvCR1avJPK1fSXs2VJ6SQ7Ilw36tt5LavWpoY I6Nw5+nhouwdQCOYBfTm2iphSx9VRPBWGvJdy/YL/mek2AJhzb8TtiWPqWzeGyyaEzYp cwmt+Ov9wOisspva/ZOXpbj8oiSOlEilVF0BisTKA8UPGjxltbVy5o5NzI/waTTwDXo+ zmBXOHGzYa9mEN/cf/93dXNQXlTaqMjAloJavap/X5kA1uEykBIaV+cZab4/WsYZ74Kg Derg== X-Received: by 10.49.58.240 with SMTP id u16mr190076qeq.16.1372181533094; Tue, 25 Jun 2013 10:32:13 -0700 (PDT) Original-Received: by 10.224.178.193 with HTTP; Tue, 25 Jun 2013 10:32:12 -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:c01::236 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:161036 Archived-At: 2013/6/25 Stefan Monnier : >> Well, the list is long: > > Just to clarify: the reason why all this has changed without any > discussion is because there was not supposed to be any API. > `package.el' was only meant to provide an interactive UI, pretty much > (plus a few functions, basically the autoloaded ones). That is pretty unfortunate=E2=80=A6 > >> - "package-archive-contents" and "package-alist" have different >> contents now, because the package descriptors have changed, > > Right. This won't be "fixed". > >> - "package-delete" takes a single argument only, but used to take two, > > We could definitely "fix this". I didn't say you should =E2=80=9Cfix it=E2=80=9D, and I don't think you sho= uld actually. The =E2=80=9Cnew API=E2=80=9D is much better than the old one wi= th two arguments. And it's not too hard to handle this situation in Carton: We'll just test for the presence of a "package-desc" constructor, and use the new API in this case, or the old one otherwise. I just said that things would have been easier for us, if we had been made aware of these changes, e.g. by the NEWS file or some other kind of announcement. Had I not followed this list, we would not have noticed these changes at all, and would probably have reported pointless bugs for them. >> - "package-install" doesn't accept a package name anymore, > > It does (again). Fine, thank you :) >> Since most of these changes come from the introducing of >> "package-desc" struct, I know that I am out of luck. > > Indeed. > >>> What API? >> Well, the package.el API, that is, "package-install", >> "package-delete", "package-alist", and unfortunately a number of >> internal functions ("package--*"), too, because the public API is >> somewhat limited. > > Tell us what you need, then, and we can improve it. As mentioned, what > you think as the public API doesn't even really exist, so the design is > very much open. Well, we need an API to - install packages by name (e.g. "package-install") - update the package archive contents (e.g. "package-refresh-contents"), - and to get a list of upgradable and obsolete packages (uhm, don't know, we currently call all sorts of internal "package-menu--*" functions). Another point on the wishlist would be to control all the output of package.el, mostly to suppress all sorts of byte-compiler and autoload generation messages which are meaningless to the user, unless there is an error. >> For an end user, it's just a declarative way to specify all packages >> used in her configuration, > > I'd like to move in that direction: instead of letting the user say > "install foo" and "uninstall bar", I'd like her to configure the "list > of installed packages" (so adding an element installs it along with any > dependencies, and removing from the list uninstalls the package (if it > was installed) along with any of the dependencies which aren't needed > any more). > >> installable with a single shell command, but for a package developer, >> it maintains an isolated, automated and repeatable package environment >> for testing. > > As you've discovered, Emacs's development is very messy, so it's no > wonder I've never felt the need for such a controlled testing environment= . > >> Essentially, it's Bundler, but for Emacs Lisp. > > That tells me more about what is Bundler than about what is Carton > (I've never used Ruby or any of its tools) ;-) Oh, sorry, I didn't know this, or I would have used some other analogy. I just made the experience that people usually don't get what Carton does until I drop the magical word "bundler" at which point lights go on and everything's clear :) What languages do you use? They might probably have similar tools=E2=80=A6