emacs-devel
[Top][All Lists]
Advanced

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

Re: Integrating package.el


From: Ted Zlatanov
Subject: Re: Integrating package.el
Date: Wed, 24 Feb 2010 15:20:58 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.91 (gnu/linux)

On Tue, 23 Feb 2010 17:25:17 -0500 Stefan Monnier <address@hidden> wrote: 

>> What remains to be done to make package.el a part of Emacs?  I think
>> Dan Nicolaescu's suggestion about menus makes sense.  Is there anything
>> else?

SM> For me, the only thing holding it back is the ability to concurrently
SM> install different versions of the same package.

SM> E.g. the sysadmin may install a whole bunch of packages and even
SM> different versions of those packages, and then each user gets to choose
SM> which ones to use in her ~/.emacs.

Phil and other ELPA folks, please comment, here are my opinions.

Emacs could recognize the Version header and always track it internally
when it loads a library file, maybe with a (version . "1.2") in the
load-history.  That would help a lot, I think.  There's already good
logic in package.el for tracking its own installations and they are
required to have a version.  They get installed as 

$prefix/NAME-VERSION/NAME.el

which is a good way to resolve path conflicts.

I think we should ensure this works in common scenarios; the users who
break package.el in ways we haven't anticipated should either stop using
it, submit patches, or suffer.  I think that's reasonable, especially if
it happens as a major upgrade (in Emacs 24 perhaps).  The fact that
there are many happy users of package.el today shows that it's all right
even in its current form.

I also think that once package.el is available from within Emacs, many
of the custom installations will simply become redundant or be reduced
to ELPA-style repositories local to the site.  So the need for handling
edge cases will shrink as word spreads.

Ted





reply via email to

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