[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future role of ELPA
From: |
Stefan Reichör |
Subject: |
Re: Future role of ELPA |
Date: |
Tue, 16 Feb 2016 19:51:38 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
John Wiegley <address@hidden> writes:
>>>>>> Stefan Reichör <address@hidden> writes:
>
>> My main concern with GNU ELPA is that I have to install a lot of extra
>> packages manually using the package manager. When they are built-in they are
>> just there.
>
> Hi Stefan,
>
> Have no fear: I never use package.el myself, since I also prefer to curate
> hand-installed packages.
>
> So what does moving to ELPA mean?
>
> There would be a large set of ELPA packages (maybe all of them to start) that
> will appear in the tarball when you download and install Emacs. This means --
> I think -- that they should populate the site-wide site-lisp directory, and
> appear to users as if they had come "with Emacs"; that is, either autoloading
> or a manual `require' statement to make the functionality available.
>
> There are a few advantages to this:
>
> 1. After installation of Emacs, package.el can be used to upgrade select
> packages independent of our release cycle.
>
> 2. Developers can get packages into the Emacs distribution without having to
> justification inclusion in core.
>
> 3. Code "in development" is free to appear in ELPA, whereas we tend to frown
> on APIs that will change often in Emacs itself.
>
> The bottom line is that, as a user, you shouldn't notice much difference after
> installation, but you'll gain the benefit of optionally performing frequent
> updates of ELPA packages. As an Emacs developer, the advantage is that it
> simplifies the Emacs Git repository, and makes it easier for external authors
> to focus on maintaining their packages within ELPA.
I see.
A simpler way to upgrade selected packages is good thing.
Some things that should be considered for the package system:
1. Not only emacs provides a package manager. Linux distributions also
provide some packages. Not sure if this is a good idea.
The same situation is e.g. for python. You can use pip to install
packages. And there are python packages provided by distributions.
Some people prefer OS packages, some prefer the native package manager.
Not sure what to do about this situation.
2. The packages should not be too fine grained. It is not very useful to
split e.g. tramp in 20 sub-packages for example.
I don't want to be overwhelmed by 100s or 1000s of packages.
Perhaps we could have some kind of installation counter to find
useful packages. Or even some kind of voting system.
Stefan.
- Future role of ELPA (was: [ELPA] tramp-theme.el), (continued)
- Future role of ELPA (was: [ELPA] tramp-theme.el), Stefan Reichör, 2016/02/16
- Re: Future role of ELPA, Christian Kruse, 2016/02/16
- Re: Future role of ELPA, Michael Albinus, 2016/02/16
- Re: Future role of ELPA, Christian Kruse, 2016/02/16
- Re: Future role of ELPA, Michael Albinus, 2016/02/16
- Re: Future role of ELPA, Christian Kruse, 2016/02/16
- Re: Future role of ELPA, Przemysław Wojnowski, 2016/02/16
- Re: Future role of ELPA, Oleh Krehel, 2016/02/16
- RE: Future role of ELPA (was: [ELPA] tramp-theme.el), Drew Adams, 2016/02/16
- Re: Future role of ELPA, John Wiegley, 2016/02/16
- Re: Future role of ELPA,
Stefan Reichör <=
- Re: Future role of ELPA, Michael Albinus, 2016/02/16
- Re: Future role of ELPA, John Wiegley, 2016/02/16
- Re: Future role of ELPA, Richard Stallman, 2016/02/17
- Re: Future role of ELPA, Stefan Monnier, 2016/02/20
- Re: Future role of ELPA, Philipp Stephani, 2016/02/21
- Re: Future role of ELPA, Stefan Monnier, 2016/02/21
- Re: Future role of ELPA, Richard Stallman, 2016/02/21
- Re: Future role of ELPA, Richard Stallman, 2016/02/22
- Re: Future role of ELPA, Phillip Lord, 2016/02/17
- Re: [ELPA] tramp-theme.el, Alexis, 2016/02/16