From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hackney Newsgroups: gmane.emacs.devel Subject: Re: cl-defstruct-based package.el, now with ert tests and no external tar! Date: Tue, 25 Jun 2013 18:07:51 -0400 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 X-Trace: ger.gmane.org 1372198101 25147 80.91.229.3 (25 Jun 2013 22:08:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 22:08:21 +0000 (UTC) Cc: Sebastian Wiesner , Dmitry Gutov , Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 26 00:08: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 1UrbPP-00078w-D2 for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2013 00:08:19 +0200 Original-Received: from localhost ([::1]:43106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrbPO-0003Mz-HM for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 18:08:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrbPJ-0003Mq-8p for emacs-devel@gnu.org; Tue, 25 Jun 2013 18:08:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrbPI-0002io-7A for emacs-devel@gnu.org; Tue, 25 Jun 2013 18:08:13 -0400 Original-Received: from mail-ie0-x22c.google.com ([2607:f8b0:4001:c03::22c]:45448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrbPH-0002ii-VF for emacs-devel@gnu.org; Tue, 25 Jun 2013 18:08:12 -0400 Original-Received: by mail-ie0-f172.google.com with SMTP id 16so29509826iea.31 for ; Tue, 25 Jun 2013 15:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=haxney.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QiuF7nLJ7qFQdOCFhix8BCdoG6VbolGjIOJLrSuGzwM=; b=thdCD0N9K0+McYKsoujjtR/05hEsga0cQs+P26Eehm3i/V3rV7SZQZG+MdXonKZSs6 tV6tTkZWIwVloWzecHY6OMBLntehvr0G0SdgkLo68X92/WbFiZ/XkLuDcj7bLfaCFsxg 77OWcVZtXrf73k0Omn8y0ta/OVnSio3hCJdq4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=QiuF7nLJ7qFQdOCFhix8BCdoG6VbolGjIOJLrSuGzwM=; b=cUfTb6aLSoHlqqqyouWUT4zxLBXtB/oVYz8fteWPStKmjBrZcwUs0+sO0GWLYctyrb F9buvjQFOh/NB1wnbCCWF+4stqhFdoJn9KY6vvWcG5woSN+rScLNC0DoueHv4QNPdqFY dI9fAESmvi4V9HzQ1r6xvdlA4H0aQu8sqGcAktVy/XQLwIF3pbbUoDgRX0tnioHE5331 zXVfP1Bx7pyH7/Fsmr3W0DIGGqoV28W2vY/x8ikDKCJAC121eYgkh/JK4+5rLwPceLny pQbu9VFHWZFxIODy7bX3Uc4l22XUM/m3LM57dmbDykoHCgB4MI10cKcsTyEHbxHYx4eW fs2g== X-Received: by 10.50.73.226 with SMTP id o2mr694260igv.22.1372198091433; Tue, 25 Jun 2013 15:08:11 -0700 (PDT) Original-Received: by 10.64.141.49 with HTTP; Tue, 25 Jun 2013 15:07:51 -0700 (PDT) In-Reply-To: X-Gm-Message-State: ALoCoQlKipvm810SADE9KRw5K0nS6OX3R3iy5E/7+PJnPvD1eEHVbZehvB/1NrW1yaUImmYzg6i0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::22c 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:161060 Archived-At: Stefan Monnier wrote: >> 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). Part of the motivation for my changes was to give package.el more of an API which would be usable by developers. There is certainly plenty more which could be done, like having more of the refresh and mark-upgradable functionality present in non-UI functions. >>> 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. I separated things according to the principle of foo-public and foo--private, so (theoretically) libraries using package.el should only have to use package-foo functions and variables and none of package--bar. > 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. I intended to define a public API which would be solid enough to be considered stable(ish). >> Essentially, it's Bundler, but for Emacs Lisp. I had thought about/proposed something along similar lines when looking into version-parsing libraries [1], but was told that since Emacs is not a production environment, it's not worth worrying too much about exact version compatibility ranges (as in "package foo depends on package bar >= 1.2.3 and < 1.3.0). Given that MELPA uses simple date stamps from development versions, fine-grained control over dependency graphs does not seem to be that important. But who knows, maybe the presence of better version management will enable more complex dependencies. [1] http://www.haxney.org/2010/03/comparing-emacs-version-parsing.html -- Daniel Hackney