help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: using use-package


From: Stefan Monnier
Subject: Re: using use-package
Date: Thu, 13 Aug 2015 11:08:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> FWIW, and based on a recent experience of mine, yes, I think both ways
> are needed/useful and complement each other. Recently, I installed some
> package from ELPA (magit) and it failed to byte-compile. I've yet to
> investigate what went wrong (perhaps my Emacs version is too new/old,
> what have you), but I now find myself wrangling with the complexities
> of the package itself *and* those of the packaging system.

Please do keep us informed of those problems: it's indeed very important
to make package.el more robust.

In the mean time, you can do:

   mv ~/.emacs.d/elpa/magit/*.elc ~/somewhere-for-analysis/

which should "fix" the problem (Magit will be slower, tho).

We should probably also add a package-(re)compile command (after all,
the compilation step is conceptually independent from the actual
installation).

> So some "wholly integrated solution" makes life easier only when things
> work out (duh ;-) Otherwise it makes life harder, and what's more important
> in my view -- it tends to make a stronger separation of "outer circle"
> and "inner circle", making it more difficult to get involved.

I tend to agree.  My earlier package system attempt had less magic
power.  The main visible difference, is that instead of
(package-initialize), the user had to use a bunch of (load
"/foo/bar/pkg-autoloads.el") to activate each package.

But fundamentally, (package-initialize) still does just that (i.e. it
first looks for all installed packages, decides which to activate, in
which order, and then does the corresponding `load's).

Patches/suggestions to make this magic more transparent welcome.

> Perhaps the only problem is in this "differently": if ELPA and use-package
> manage to converge towards some set of common conventions, the end-user
> is only to win (whereas I'm convinced that there must be a first phase
> of divergence: how else are we going to explore different options?)

Agreed.  Hence my participation in this thread ;-)


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]