Re: Integrating package.el

[Ted Zlatanov]

On Mon, 1 Mar 2010 17:26:46 +0100 Jonas Bernoulli <address@hidden> wrote: 

JB> Without actually having looked at package-maint.el I believe that
JB> elm.el is more advanced - so I have heard and do in part
JB> believe... At least the metadata that I generate is *different* from
JB> that generated by package-maint.el or manually; and used by
JB> package.el. I think the data I generate has some advantages - mainly
JB> I do extract more information.

Can you or Phil/Tom explain the metadata capabilities of elm.el and
package-maint.el respectively, please?  It would help to know what the
authors think and do a side-by-side comparison.

JB> Of course anyone is free to generate the package list as required by
JB> package.el himself.  This could either be done by using the metadata
JB> I have generated and converting it [1] [2] or by getting a recent
JB> tarball [3] of all the git directories of all mirrored packages and
JB> generating it directly using package-maint.el.

That may be necessary if package.el becomes the default package manager
in Emacs.  It doesn't seem too hard since, as you say, the ELPA-style
metadata is a subset of the Emacsmirror metadata.  It would also be
possible to make a special package.el setup for Emacsmirror which would
pull elm.el and manage elm.el packages through it, if that was required.

JB> I am working on git support as I do think it has some considerable
JB> advantages - generally people seam to disagree.  Since I think using
JB> a dvcs instead of tarballs should be preferred I have absolutely no
JB> interest in working on generating tarballs myself.

I agree.  2100 packages over HTTP is crazy, an update would be very
costly whether you use a single database or one per package.  OTOH for a
few packages or specific situations HTTP makes sense so it's a matter of
providing a uniform frontend over various backend protocols.

JB> Also I do not much feel like discussing this anymore.  At this point
JB> I simply have nothing that would demonstrate the benefits and at the
JB> same time I doubt that anyone can come up with an argument that
JB> would convince me that it's not even worth writing a
JB> prove-of-concept.

Your input is valuable at any stage in the discussions, so thank you for
contributing.

Ted