From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Interoperation between package managers Date: Sun, 13 Aug 2017 19:32:38 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1502667264 24898 195.159.176.226 (13 Aug 2017 23:34:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 13 Aug 2017 23:34:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 14 01:34:19 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dh2Oa-0005oy-Cy for ged-emacs-devel@m.gmane.org; Mon, 14 Aug 2017 01:34:12 +0200 Original-Received: from localhost ([::1]:47208 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dh2Og-0005Jd-MH for ged-emacs-devel@m.gmane.org; Sun, 13 Aug 2017 19:34:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dh2NE-0005Fw-4N for emacs-devel@gnu.org; Sun, 13 Aug 2017 19:32:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dh2NB-0007mB-0o for emacs-devel@gnu.org; Sun, 13 Aug 2017 19:32:48 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:39830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dh2NA-0007lY-RC for emacs-devel@gnu.org; Sun, 13 Aug 2017 19:32:44 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v7DNWeW7005026; Sun, 13 Aug 2017 19:32:40 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id DA46A66334; Sun, 13 Aug 2017 19:32:38 -0400 (EDT) In-Reply-To: (Radon Rosborough's message of "Sun, 13 Aug 2017 15:42:48 -0700") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6092=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6092> : inlines <6018> : streams <1758472> : uri <2482574> 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.21 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" Xref: news.gmane.org gmane.emacs.devel:217526 Archived-At: >> I'd probably want to also unify the two files into one (which would >> likely hold the concatenation of -pkg.el and >> -autoloads.el). > I'm a little wary of this idea. It seems to me like -autoloads.el > is purely an implementation detail (or "build artifact") of the > package manager, whereas -pkg.el contains author-maintained > metadata that should be checked into version control in the upstream > repository. My view is that -pkg.el should be built from metadata stored elsewhere (that's what we do in elpa.git). >> I think it's very important to be able to have several versions of a >> given package installed at the same time. > This is another concept which makes a lot of sense in the > tarball-from-ELPA workflow, but not much sense in the source-based > workflow (where you don't need to save old versions because you can > revert to any version at any time). I was thinking about it in the context of packages which can come from the user's config as well as from the system (i.e. installed by the sysadmin). There are other cases where it can make sense. E.g. have both foo-1.0 and foo-2.0 installed at the same time, because foo-2.0 requires Emacs-25 and you use both Emacs-25 and Emacs-24. I agree that these needs aren't the most common ones, but you don't gain anything by disallowing them, really. >> Specific requests (especially patches) are very welcome here. > Unfortunately, I can't contribute patches since I am already too busy > maintaining my own package manager. However, I can give some > suggestions for things that need to be explained. These look like info about the internals, and indeed we don't document them very much. Some of them are purposefully not documented ("use the source, 'cause it might change"). But there's a a lot of room for improvement anyway. I'll see if I can improve on that. > * What is the format of a package on the server? AFAIK this is documented somewhere. > * What does activating a package mean? Again, I know that it entails > evaluating the autoloads file and adding a directory to the load > path, but most people don't. Actually "adding a directory to the load path" is only there by accident: it should be done by the autoloads file. > * Why is package-initialize so slow? I don't know that it is, so I can't answer the question. > What are the bottlenecks when you > activate lots of packages? I haven't looked into. If you find performance problems, M-x report-emacs-bug is probably the best option, so we can try to find how to improve the situation. > Maybe package.el is simple, but unless there's a clear statement that > "this documentation covers exactly what package.el does", there's > always the concern that more magic is going on, given how opaque the > source code is. The source code of package.el is not supposed to be opaque. I wasn't the original author and I didn't find it opaque when I looked at it. So if it's opaque, maybe it's my fault, but I'm probably not the right guy to fix it, then ;-) Stefan