Re: Future role of ELPA

["Stefan Reichör" <stefan@xsteve.at>]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stefan Reichör <stefan@xsteve.at> 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.