Re: Integrating package.el

[Jonas Bernoulli]

2010/3/1 Ted Zlatanov <address@hidden>:
> On Tue, 19 Jan 2010 03:40:11 -0800 Phil Hagelberg <address@hidden> wrote:
> PH> I've just implemented support for multiple package sources in
> PH> package.el. Right now it is preconfigured to use ELPA, but the following
> PH> snippet will let it pull in packages from my own archive source as well:
>
> PH> I'd love to see some other elisp library authors try to set up their own
> PH> package archive sources using package-maint.el and test the
> PH> multiple-archive support.
>
> PH> I hope that a new version of package.el incorporating my changes could
> PH> be pushed out to ELPA and then possibly included in Emacs once a little
> PH> more work has gone into integration with the Emacs load process.
>
> Jonas, have you looked at this update to package.el?

No, I have not found the time yet but I am aware that Phil has added
this feature [0].

> Any chance you can make your Emacsmirror accessible as a package.el 
> repository,

Not immediately. Of course I do want the Emacsmirror to support (a)
package manager(s)
but due to lack of time I have concentrated on mirroring (adding and
*keeping up-to-date*)
packages.

I also haven't updated the metadata which I generate using elm.el in a
long time. But this
is next on my todo list - I might actually do this today so after that
I will hopefully find some
time to look into package-maint.el. (While I haven't pushed any
updates to the metadata I
have worked on improving the code used to generate it though.)

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

Also I do store it in one file per package instead of just one file
(which would be huge given
that now more than 2100 packages are being mirrored). In the future I
would like to extend
this to one file per package version. (I used to have support for this
but dropped it because
it is not clear yet how manual fixes would be merged when new versions
are released.)

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

Do not misunderstand me - I do plan to support package.el in the
future. But right now I
am working on other things.  Also I am more than willing to support
anyone who would like
to experiment with this.  It might actually be a good idea to test
package-maint.el using
the 2100 packages in the Emacsmirror tarball. Right now it probably
has only been tested
with some selected packages which closely follow the conventions - but
I have seen things
you people would not dream of - attack ships on fire...

> over HTTP or through patched-in Git/SVN support in package.el?

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

Again, like for package.el-style-metadata, that does not mean that I
won't add support for
tarballs if someone else writes the code.  I just do not have an
interest in doing it myself.

I will quietly work on git support and once it is ready people can
test it and decide whether
it does have advantages that out weight the cost of requiring users to
install git or not.

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

So in summary: I do wish package.el and the Emacsmirror to support one
another but due
to lack of time, different priorities and because it is unclear which
of the two has to go how
far to meet the other it is not a short term priority.

-- Jonas

[0] And I do not know if anyone has found the time to look at my
alternative: elm.el.
[1] Though while generally more informative it also lacks some
information required by package.el.
[2] But please wait until I have updated it. As of now it contains
some severe bugs.
[3] http://github.com/emacsmirror/elm-backup-pkgs