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: cl-defstruct-based package.el, now with ert tests and no external tar! Date: Tue, 25 Jun 2013 14:23:21 -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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372184613 32482 80.91.229.3 (25 Jun 2013 18:23:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 18:23:33 +0000 (UTC) Cc: Emacs development discussions , Daniel Hackney , Dmitry Gutov To: Sebastian Wiesner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 25 20:23:32 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 1UrXtq-0007Pz-Sy for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 20:23:31 +0200 Original-Received: from localhost ([::1]:55343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrXtq-0004aR-92 for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 14:23:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrXtm-0004aM-Ge for emacs-devel@gnu.org; Tue, 25 Jun 2013 14:23:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrXtk-0004yl-UR for emacs-devel@gnu.org; Tue, 25 Jun 2013 14:23:26 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:57907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrXtk-0004yZ-Q8 for emacs-devel@gnu.org; Tue, 25 Jun 2013 14:23:24 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r5PINMO1009300; Tue, 25 Jun 2013 14:23:22 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 4694EB4178; Tue, 25 Jun 2013 14:23:22 -0400 (EDT) In-Reply-To: (Sebastian Wiesner's message of "Tue, 25 Jun 2013 19:32:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4620=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4620> : streams <988840> : uri <1458347> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:161037 Archived-At: >> 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 Agreed. But that's what we have to work with. >>> - "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 s= hould > actually. I thought so (it might have been worthwhile if it had been the last incompatibility left). > 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. It would have been easier for us if you had announced Carton here (or on gnu.emacs.sources or some such place), so we'd have known that someone was using the actual code rather than the UI ;-) >> 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") Done ;-) > - update the package archive contents > (e.g. "package-refresh-contents"), Done ;-) > - and to get a list of upgradable and obsolete packages (uhm, don't > know, we currently call all sorts of internal "package-menu--*" > functions). While the previous two sound "clear enough", this one has many more options. One possibility is to provide a `package-list' function which returns all known packages. Then you can use the (new) package-desc-dir to know if it's an installed packages or a package from an archive, and package-desc-status to figure out if it's obsolete (tho making this function return symbols rather than strings would be preferable if used like this). > 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. I like for users to see the warnings, since it can give them a sense of potential problems (e.g. if something is obsolete), and in the absence of a maintainer (unmaintained packages are pretty much the rules rather than the exception in Emacsland), it can be very useful: they may not be able to fix it themselves, but at least they may bring it up so someone else can fix it. But having more control over this output (and prettifying it) would indeed be very welcome. It is fairly intimidating/overwhelming as it stands. Maybe we could try and make it possible to redirect it to a particular buffer, so you can later on clean it up before displaying it. > What languages do you use? They might probably have similar tools=E2=80= =A6 Agda, Coq, Haskell, C, Elisp? Stefan