Re: Integrating package.el

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 3 Mar 2010 21:39:17 -0800 Phil Hagelberg <phil@hagelb.org> wrote: 

>> Have you considered support for non-HTTP sources?  I'm OK with HTTP only
>> for now but I think a Bazaar source would make sense if there's going to
>> be a ELPA-style repository inside Emacs itself.  Also are file:/// URLs
>> supported?

PH> Rather than supporting installing straight out of a VC repository, I
PH> have opted to make it easy to create an archive from a list of VC
PH> repositories. (package-maint.el) The idea is that only releases
PH> would be included in the archive rather than any-old-version.
PH> This also reduces the dependencies on the client-side.

OK.  See below about file:/// URLs.

PH> If you want to add support for installing directly from a VC repository
PH> don't let me stop you, but I think there are more important things to
PH> do first.

Understood.  The TODO list has more important items, I agree.

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

PH> I want to look at the menus patch soon, but I haven't found the time
PH> yet. 

Great, thanks!

PH> Stefan also mentioned supporting having multiple versions of the
PH> same project installed at once. Rather than supporting this by
PH> allowing multiple versions to coexist in a single install location,
PH> I think it makes more sense to allow multiple install locations. I
PH> haven't thought through the implications of this though. Perhaps it
PH> would be as easy as simply activating the newest version available,
PH> but perhaps we need something more explicit. Probably some mechanism
PH> would be necessary for allowing users to opt-out of system packages.

PH> I think supporting the distinction between system-level installs vs
PH> user-level installs is the biggest blocker (besides more thorough
PH> testing) to including package.el in Emacs. I would like to implement
PH> this, but it probably won't happen within the next month unless
PH> someone else steps up to start work on it.

How about associating a single install location with each repository?
Logically that would make sense and there would be a default (nil)
repository for things not managed by package.el.  Then the user, by
managing the repository priority, would also manage the load-path
priority.

>> Phil hasn't replied to questions in this thread for a bit so he must
>> be busy as well.  Would it be OK if I worked with the Emacs
>> maintainers to patch up Phil's latest package.el so it can go into
>> Emacs?  Or should I wait a bit longer?  I really don't mind waiting,
>> but if I can help...

PH> Don't wait on account of me. I definitely want to see this through,
PH> but if you're able to put work into it now then go for it.

Can you review Dan Haxney's (CC here and to you) patches as well at
http://github.com/haxney/package?  He supports file:/// URLs and has
made many other improvements.  I don't know if he has rebased against
your support for multiple repositories.  If the two of you could decide
what pieces are worth keeping and merge, it would make it easier for me
to start work on the merged version.  Otherwise I may end up wasting
effort.

Thanks
Ted