[Top][All Lists]
[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