[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Package Management
From: |
Phil Hagelberg |
Subject: |
Re: Emacs Package Management |
Date: |
Sat, 12 Sep 2009 15:38:04 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
Tom Tromey <address@hidden> writes:
> Just FYI -- package.el (the elisp side of ELPA) does handle
> dependencies.
>
> There was a discussion a while ago on this list. RMS wanted to
> restrict the available packages to those which had been assigned to
> the FSF, but I did not agree with that.
>
> I would reconsider my position if the Emacs maintainers were
> interested -- I think it would be useful to Emacs users if there were
> a simple, standard way to install and activate packages.
It seems like the dust has settled a bit since the 23 release and we're
out of feature freeze; I wonder if this would be a good time to discuss
the inclusion of package.el again. I've been using it extensively as
well as distributing all of my own elisp through it, and it has greatly
simplified things for me and the users of my software.
Some people have asked what the use would be; why not just include them
in Emacs itself? There are several reasons:
* Much of my elisp is still undergoing a rapid rate of change. Often
versions from two months ago are quite out of date. Using package.el
lets me use my own release cycle rather than relying on Emacs', which
is much improved, but still not appropriate for many projects.
* Emacs is already too big. If we made it easy to install third-party
packages, we could spin many packages already included in Emacs
(perhaps gnus, erc, and org) out into their own independent
projects. We would avoid problems like "the big gnus merge" that
happens every so often as well as allowing them to follow their own
release cycles. In addition, a lot of packages are simply fringe;
they're only useful to a small subset of Emacs users.
* I make use of the cl library, disqualifying much of my code for
inclusion in Emacs proper. I'd venture to say close to a majority of
the nontrivial packages out there do as well.
It sounds like the main objection to its inclusion is that it would
lessen the incentive to assign copyright to the FSF. I don't think this
is necessarily the case; we can hook it up to a repository that only
accepts FSF-copyrighted code. I would be happy to contribute copyright
assignment for the libraries I maintain if it meant that they could be
offered via a package manager built-in to Emacs. I suspect many others
would too.
There would be some work involved in making package.el acceptable for
Emacs. Currently uploading of new packages is done by hand; this process
will need to be automated. Perhaps it could be integrated with Savannah
project hosting; I'm sure something could be worked out.
But I think this is a big opportunity to make it easier for developers
and users of Emacs to share code.
-Phil
- Re: Emacs Package Management,
Phil Hagelberg <=
- Re: Emacs Package Management, Eric M. Ludlam, 2009/09/12
- Re: Emacs Package Management, Richard Stallman, 2009/09/13
- Re: Emacs Package Management, joakim, 2009/09/14
- Re: Emacs Package Management, David Kastrup, 2009/09/14
- Re: Emacs Package Management, Richard Stallman, 2009/09/15
- Re: Emacs Package Management, Miles Bader, 2009/09/15
- Re: Emacs Package Management, Richard Stallman, 2009/09/15
- Re: Emacs Package Management, Tom Tromey, 2009/09/15
- Re: Emacs Package Management, Miles Bader, 2009/09/15
- Re: Emacs Package Management, Richard Stallman, 2009/09/16