From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: Interoperation between package managers Date: Thu, 10 Aug 2017 19:14:15 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1502417714 2051 195.159.176.226 (11 Aug 2017 02:15:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 11 Aug 2017 02:15:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 11 04:15:10 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 1dfzTa-0008Aq-NS for ged-emacs-devel@m.gmane.org; Fri, 11 Aug 2017 04:15:03 +0200 Original-Received: from localhost ([::1]:46763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfzTf-0005Wf-D4 for ged-emacs-devel@m.gmane.org; Thu, 10 Aug 2017 22:15:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfzTW-0005Vs-NW for emacs-devel@gnu.org; Thu, 10 Aug 2017 22:14:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dfzTV-00021w-8c for emacs-devel@gnu.org; Thu, 10 Aug 2017 22:14:58 -0400 Original-Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:35435) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dfzTV-00021k-0q for emacs-devel@gnu.org; Thu, 10 Aug 2017 22:14:57 -0400 Original-Received: by mail-lf0-x234.google.com with SMTP id t128so10717333lff.2 for ; Thu, 10 Aug 2017 19:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hzEMfRJ+ui0070H9tpsBJWeVPRVmR86m/rmYBpzWNJY=; b=r3Wzl3BrXx2Z0WE53LIh9uGoImMWGCLP6vBgFJYzHfu6CLFjBC8MBT6Xm5Ln8NnNZ3 1LCcaYR0Ga4mUOn5rQlK89Uv30ZCThnCJ1u+2qZ4ZvFXwY2+Hqn/HiaitY/YlfrFOdFY TdZEH9yK6Qk34dAHs202fNrugEb8LXvAvuF94x0LYIWZVYk/b4M5YCSBtan2qDR3vFTC hpli4nwiso/sLvTM+sqPPt1POYWagGuFig64DX6ShDPn85bB7a9qG8lqT+hVwL24nlxS OALIva8q56pz7aYoxjkMDrQWh8zGxxZ7ViUDeb/9wHdV8ISnSyXy7UhqiLj4VXxLjIfO twwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hzEMfRJ+ui0070H9tpsBJWeVPRVmR86m/rmYBpzWNJY=; b=t2yxrw64AVwppAIuf6pIGYDGTdCowcJmD2OSYiThNRVG8Y4fnzG2ViuczFTWkuKbBi +x36BY4KGszKKR2pYSAl+qPmPcCFdi7oakJQlHYNDDyQv7Xx/TAu51uYKOHzEBgP8PW6 X4e8fgjErsE1Fb/f5wxMnEFe/ywRVSZEmcPAxC1hCsWprokiUqmSRH7AICS+48mV51WM /U729g7hJwKoq0ROdsTobgGhZoR7qdBLgOB45J8FROh0kj3M8LYP35vqqHt5ctGQzW6O 66oigLZl8KMICPEkHHbkpQr8Nnnnm9DayzRCU7gltmS2NCv4573DEcx/KXnhSimN0FoZ JwiQ== X-Gm-Message-State: AHYfb5jyzeZbA9dJW2r7DcMNYoWHtPQpzLWKrl5CexkPWpvEBTFGGg0G T0fVSzB9QjIKePTuFw08DVtDh/P8LQ== X-Received: by 10.46.64.73 with SMTP id n70mr5659829lja.120.1502417695599; Thu, 10 Aug 2017 19:14:55 -0700 (PDT) Original-Received: by 10.46.64.86 with HTTP; Thu, 10 Aug 2017 19:14:15 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::234 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:217407 Archived-At: > I don't know what you mean by "the package.el format". I meant the one in ~/.emacs.d/elpa. > the way I use elpa.git with package.el is: > > git clone .../elpa.git > cd elpa > make > > and then add that directory to package-directory-list. > That lets me use packages directly from the local Git repository (which > I find important in order for `C-h f` and such to directly jump to > the real source files that I can edit, with VCS metadata). I had no idea that package.el was capable of this. Thank you for informing me; I will have to amend some of my published criticisms of package.el. I have actually never seen anybody else doing this with package.el, or indeed any mention that such a thing was possible. Thus, I have a couple of follow-up questions: - Is this use case documented in any way? I looked at the docstring for `package-directory-list' and it just said that the variable is for system-wide use only, and that you should use `package-user-dir' for your personal packages. Notably absent was any mention of what "directories containing Emacs Lisp packages" means, since all sorts of different formats could be expected. - I had originally assumed that `package-directory-list' included packages in an ELPA-server-compatible format, and that package.el would display these packages in `package-list-packages', and you could install them into ~/.emacs.d/elpa (thus making copies of the files). You are saying this is not the case, right? - Is this the intended way to use package.el? Every tutorial I've seen only covers installing packages from a local or remote ELPA repository. - When you modify a package, how is byte-compilation and autoload generation handled? Do you just have to run 'make' again? Does that mean you have to hope that every package's Git repository provides a byte-compilation and autoload generation mechanism, and then remember how to use each of them? (Here I am talking about packages that are not in GNU ELPA, i.e. the majority of them.) - Does package.el officially support installing packages from version-control, or do you have to clone and manage the repositories manually? If not currently, is such support a future development target for package.el? So package.el interop may indeed be useful for Borg. It will not be useful for straight.el regardless, since straight.el makes compatibility with package.el an explicit non-goal. But in any case, I think the standardization you have proposed is a great idea, since it appears that every package manager other than straight.el could benefit from it. Best, Radon