[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary and next steps for (package-initialize)
From: |
Radon Rosborough |
Subject: |
Re: Summary and next steps for (package-initialize) |
Date: |
Sun, 20 Aug 2017 10:21:40 -0700 |
> Thanks for putting this proposal together. Can you explain what
> advantages it holds over my previous proposal, which didn't require
> creating an init file if there was none, nor having an explicit
> package-initialize form?
Sure. I think your proposal would work in principle, but it seems like
an unnecessarily complicated way to solve a simple problem. No other
package in Emacs requires this level of infrastructure just to
customize and use it: why does package.el need it? (I've asked this
question before, comparing package.el to other packages and package
managers, and have not yet received an answer as to why package.el has
to be so special.) That said, here are the concrete disadvantages I
see with your proposal:
* It is impossible to customize `package-load-list'. If
`package-initialize' is called before loading the init-file, and
then I call `package-set-load-list' in order to load only a subset
of packages, it won't have any effect since all the packages were
already loaded the first time `package-initialize' was called. Since
`package-initialize' is called once, explicitly, in my proposal,
there is no such problem.
* More generally, `package-initialize' will be called before my
customizations of package.el. If I customize `package-user-dir',
then I think I can reasonably expect that only packages in the new
location, and not ones in ~/.emacs.d/elpa, will be activated. Not so
with your proposal; packages in both locations will be activated.
Again, this problem does not exist in my proposal since users simply
do the obvious thing: put package.el customizations before calling
(package-initialize).
* Every other variable in Emacs is customized by setting it to a
value. It is confusing for package.el to be customized by adding a
special dotfile to ~/.emacs.d. My proposal requires no such
inconsistency and therefore does not violate the Principle of Least
Surprise.
* I find it hard to believe that we won't see significant performance
regressions with the current implementation of package.el. Thus your
proposal can't be adopted until the implementation is fixed so that
calling `package-initialize' multiple times takes negligible extra
time. OTOH, my proposal can be adopted right now.
The first two points are the real problems here: fundamentally I think
it's a non-starter to call `package-initialize' before loading the
init-file. Unless, of course, you introduce a new init-file that's
called before `package-initialize', and that's a whole new can of
worms.
Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/20
Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/20
- Re: Summary and next steps for (package-initialize),
Radon Rosborough <=
Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/20
Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/20