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: Sat, 12 Aug 2017 10:54:00 -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 1502560491 11008 195.159.176.226 (12 Aug 2017 17:54:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2017 17:54:51 +0000 (UTC) Cc: Jonas Bernoulli , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 19:54:47 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 1dgacY-0002Y1-Ln for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 19:54:46 +0200 Original-Received: from localhost ([::1]:44587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgace-0006lH-W9 for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2017 13:54:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dgacY-0006kb-3N for emacs-devel@gnu.org; Sat, 12 Aug 2017 13:54:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dgacW-0000MC-Pu for emacs-devel@gnu.org; Sat, 12 Aug 2017 13:54:46 -0400 Original-Received: from mail-lf0-x231.google.com ([2a00:1450:4010:c07::231]:38776) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dgacW-0000Lr-Il for emacs-devel@gnu.org; Sat, 12 Aug 2017 13:54:44 -0400 Original-Received: by mail-lf0-x231.google.com with SMTP id y15so26658759lfd.5 for ; Sat, 12 Aug 2017 10:54:42 -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=+dlXnw8hbXd0eK/cFqwE3sIvjOaB0Kk076nr938plFY=; b=fnuX0+JW1RtH5+PU4c2bC+5X4YGDemL8eMmbBQIR/NrDGf3fUo9+jrY2x/VpydzMj1 u03ycrA4SZFAAjfv9RhjIzd81ViQPt+NwvDbpIXBYxNNxZmU1jHQ5dTsvjYH4xIuez1y yqbTv1TMNCIbtemyfIp2cqHAI8glfGNL0B8kgRGbt3E0mMFcTmuEtTgjRkgsKNnRWfAI QYsY5U6H9gCp+PZ9WPG9ujF/VAmsSMDwfRM+7/4Rt2TKvxV019h7lKyKKbo+a1yn7/gL BxbQ1oLdKziq9lLFyDRiCHV65tjDxUFbclFJQBdgxuSaoXxikHES5X28LO+4xKj8/smv m1Sg== 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=+dlXnw8hbXd0eK/cFqwE3sIvjOaB0Kk076nr938plFY=; b=RLFVanDhBflDgKNJXgSc+68LFPY7+yTWxxWBLTOm04iQXHLSrlo75AFPt0HUk5J6HH hHFHtCmXLpjVqer4PrvuGTYb6pXkaEBnCt34rU6Wryl15iRkO0UioF80WC/c6Lz8o8YA Xb+z8OdHomn0TnllfWHJm0THCbiRtdntmZMWDbuBlDGNp5ieL9c8biO1Afdk0T5O5xnw czCyEkrNc5/p+zQmbbz3Qlj/DLWJUYqmTf9AbtT4T9AmD2WMEU+DVWxwDA3Hq/1SvKFW MU9VRwdd7ShbRngxSYgKjzinyF9tOX+uJOKV6/4LBAns6yVs8wyIgP4X8jbDqDzB2E06 j7+Q== X-Gm-Message-State: AHYfb5jArvPSGBdMekDdiWRBVnLwdqA1JxN5ycgcLbQB/t1p6XbeGNJj nyWnRAftleHnHX+P9UXjprybkJLkDA== X-Received: by 10.46.88.68 with SMTP id x4mr6379888ljd.153.1502560481291; Sat, 12 Aug 2017 10:54:41 -0700 (PDT) Original-Received: by 10.46.64.86 with HTTP; Sat, 12 Aug 2017 10:54:00 -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::231 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:217490 Archived-At: > You have to clone&manage manually. > > > If not currently, is such support a future development target > > for package.el? > > Hasn't been so far. Rather than integrate it into package.el, it > could be a completely separate package that helps automate what I do > manually. I feel like I should point out that this support is exactly what is already provided by straight.el. Not that there is anything wrong with adding it to package.el as well, but you might find a reduced market for it since straight.el provides better support for this use case (because it makes this use case the *only* use case, unlike package.el which also supports installation of tarballs from an ELPA server). > Currently, the main way package.el was adjusted to help support the > "elpa.git checkout in package-directory-list" was to make it so that > packages in ~/.emacs.d/elpa don't have to use a subdirectory named > - but it can be named just (otherwise we'd need to > rename all those dirs after "git pull" to reflect the new version > numbers). This is fantastic! Those version numbers always annoyed me to no end and were in fact one of the major reasons I didn't like package.el. Glad to know they are now optional. As far as I can tell, this fact remains completely undocumented? Honestly, setting aside my philosophical differences with package.el, I think the biggest problem is the documentation. User education about `package-initialize' and stuff like that would be much less of a problem if the documentation were clear, obvious, and concise. (This means that elpa.gnu.org should *NOT* link to the "Package Installation" wall-of-text from the Elisp manual and the plain-text, developer-oriented README from the Git repo, without also providing some more comprehensible sources of information.) > As mentioned above, I haven't thought about what package.el could do > to make it easier to automate what I do manually, so if you have > suggestions for things that we could change in (or add to) > package.el to make it easier for Borg to interoperate with it, > please send them along, You should talk to Jonas (cc'd) about this as he's the author of Borg. I can't really provide much useful help beyond this point since I have no desire to use package.el for anything. Best, Radon