unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Radon Rosborough <radon.neon@gmail.com>
To: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Interoperation between package managers
Date: Thu, 24 Aug 2017 13:11:24 -0700	[thread overview]
Message-ID: <CADB4rJEDA0079ePkja-9Fn-5YtOJdUkUQdrprjiVcOshE3t9gA@mail.gmail.com> (raw)
In-Reply-To: <bebe606f-ed93-08a0-97d2-1c2999f61d40@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

> The main benefit of such API would be interoperability between
> package managers.

So to be clear, I like this proposal. But I'd like to ask whether it
will really offer a lot of benefit over the current situation.
Specifically:

> allowing for complex cases like when you want some package from
> package.el, then other packages from some other package manager,
> then other packages from package.el.

Why not just say it is the responsibility of the package manager to
let the user say which packages it is to make available and which
packages it is to leave for another package manager? That seems more
flexible and natural to me.

> dealing with autoloads

Indeed, this seems like a big problem. Because a package can run
arbitrary Lisp code in its autoloads, and the user expects this code
to be run unconditionally when the package manager makes the package
available (and in particular, *not* when a feature is required). If we
have the package installed via two different package managers, then
the only way to do this correctly seems to be to tell the package
managers which one of them is supposed to activate the autoloads --
and then we are right back at the current situation.

Would this require a restructuring of how autoloading works in
general? If so, the resulting loss of backwards compatibility
indicates that there need to be some concrete benefits to the new
approach.

                              ~~~~~

Another thing I worry about is whether this is the right abstraction
for package managers that operate in different ways than package.el.
For example, in the package manager straight.el, there is no concept
of an "installed package". Instead, you specify to load a package
declaratively in your init-file, and it is downloaded, built, and
loaded automatically if necessary. One important point here is that
the package is automatically rebuilt if it has changed since the last
init, and the process of checking for modifications takes some time.
If you care about your init-time, you probably would only want
straight.el checking for modifications to packages that it actually
loads (rather than ones loaded by a different package manager), so
straight.el must be made directly aware of which packages it is
actually supposed to load. Once again, this brings us back to the
current situation.

[-- Attachment #2: Type: text/html, Size: 2923 bytes --]

  reply	other threads:[~2017-08-24 20:11 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07  0:37 Friendly discussion about (package-initialize) Radon Rosborough
2017-08-07  1:39 ` Stefan Monnier
2017-08-07  2:16   ` Radon Rosborough
2017-08-07  2:44     ` Stefan Monnier
2017-08-07  4:12       ` Radon Rosborough
2017-08-09 20:24         ` Stefan Monnier
2017-08-10  3:32           ` Radon Rosborough
2017-08-10  4:25             ` Eli Zaretskii
2017-08-10  4:39               ` Radon Rosborough
2017-08-10  7:24                 ` Eli Zaretskii
2017-08-10 17:06                   ` Radon Rosborough
2017-08-10 19:08                     ` Eli Zaretskii
2017-08-10 19:31                       ` Radon Rosborough
2017-08-10 20:00                       ` Mark Oteiza
2017-08-11  6:14                         ` Eli Zaretskii
2017-08-11  1:25                     ` Nick Helm
2017-08-11 21:43                       ` Stefan Monnier
2017-08-09 20:35         ` Interoperation between package managers (was: Friendly discussion about (package-initialize)) Stefan Monnier
2017-08-10  3:54           ` Radon Rosborough
2017-08-10 21:34             ` Interoperation between package managers Stefan Monnier
2017-08-11  2:14               ` Radon Rosborough
2017-08-11 22:05                 ` Stefan Monnier
2017-08-12 17:54                   ` Radon Rosborough
2017-08-12 20:53                     ` Jonas Bernoulli
2017-08-13 21:43                       ` Stefan Monnier
2017-08-13 21:25                     ` Stefan Monnier
2017-08-13 22:42                       ` Radon Rosborough
2017-08-13 23:32                         ` Stefan Monnier
2017-08-14  0:29                           ` Radon Rosborough
2017-08-14  8:02                             ` Stefan Monnier
2017-08-23 19:39             ` Nikolay Kudryavtsev
2017-08-23 20:58               ` Radon Rosborough
2017-08-24 12:36                 ` Nikolay Kudryavtsev
2017-08-24 20:11                   ` Radon Rosborough [this message]
2017-08-25 14:31                     ` Nikolay Kudryavtsev
2017-08-24 15:04               ` Ted Zlatanov
2017-08-24 15:46                 ` Nikolay Kudryavtsev
2017-08-07  3:20   ` Friendly discussion about (package-initialize) Noam Postavsky
2017-08-07  4:14   ` Mark Oteiza
2017-08-08  0:47     ` Stefan Monnier
2017-08-10 20:15       ` Mark Oteiza
2017-08-10 21:29         ` Stefan Monnier
2017-08-11  1:14           ` Mark Oteiza
2017-08-11  8:03             ` Clément Pit-Claudel
2017-08-07  6:52 ` Colin Baxter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADB4rJEDA0079ePkja-9Fn-5YtOJdUkUQdrprjiVcOshE3t9gA@mail.gmail.com \
    --to=radon.neon@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=nikolay.kudryavtsev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).