Re: using use-package

[<tomas@tuxteam.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 13, 2015 at 11:08:02AM -0400, Stefan Monnier wrote:
> > 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 [...]

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

My hunch now is that the package brought with it an .elc file (probably
magit.elc) compiled with the wrong Emacs version. Removing all .elc and
recompiling the directory seems to succeed (I've ditched magit now for
anoter reason -- it doesn't like my git 1.7.x and wants 1.9.x, I'd have
to resort to an older magit, sigh). I'll try to verify (or falsify) my
hunch.

> 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).

Your proposal suggests that you have a similar hunch as mine :-)

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

Perhaps there should be a way for Emacs to find out that an .elc file
doesn't match the current binary interface (I've been stumped by
"wrong" .elc files (i.e such compiled by an Emacs with different
byte code conventions) more than once).

> > So some "wholly integrated solution" makes life easier only when things
> > work out (duh ;-) [...]

> 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.

I'll ponder a bit on it. Perhaps I can offer more than just some
half-smart mumblings :-)

> Agreed.  Hence my participation in this thread ;-)

Thanks for your work -- and your insightful comments!

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlXM+ogACgkQBcgs9XrR2kbp1ACfSk+76Db++oXnBQVlyJ5+dhS6
MwgAniZGSBxOkZkE3kuwFwo1zczWQrxH
=x3fA
-----END PGP SIGNATURE-----