Bundling GNU ELPA packages with Emacs - what are we missing?

Bundling GNU ELPA packages with Emacs - what are we missing?

[Stefan Kangas]

In Bug#39553, we discussed what is missing to bundle packages from GNU
ELPA with Emacs releases (i.e. in the tarball).  It is not clear (to me
at least) what is currently stopping us from doing that.

One thing I noted is that `M-x list-packages U' doesn't mark built-in
packages for upgrading even when there is a newer version available from
GNU ELPA.  Perhaps that's by design?  If not, it just sounds like a bug
to fix.

Which hurdles remain?  What needs doing?

Best regards,
Stefan Kangas

Re: Bundling GNU ELPA packages with Emacs - what are we missing?

[Michael Albinus]

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

> One thing I noted is that `M-x list-packages U' doesn't mark built-in
> packages for upgrading even when there is a newer version available from
> GNU ELPA.  Perhaps that's by design?  If not, it just sounds like a bug
> to fix.

Sorry to be the grinch, but I'm not sure this shall happen by
default. For example, Tramp is built-in in Emacs, and it exists also as
GNU ELPA package. Many people don't use it; why shall they be forced to
upgrade?

And, as said otherwere already, such an upgraded Emacs is different from
an Emacs started via "emacs -Q". For Tramp, it is essential to analyze
problems with an Emacs started as "emacs -Q". We would loose this
possiblitiy.

> Which hurdles remain?  What needs doing?

I believe we would need first a solution to these problems, before we
implement automatic upgrade of built-in packages.

> Best regards,
> Stefan Kangas

Re: Bundling GNU ELPA packages with Emacs - what are we missing?

[Stephen Leake]

Michael Albinus <michael.albinus@gmx.de> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
> Hi Stefan,
>
>> One thing I noted is that `M-x list-packages U' doesn't mark built-in
>> packages for upgrading even when there is a newer version available from
>> GNU ELPA.  Perhaps that's by design?  If not, it just sounds like a bug
>> to fix.
>
> Sorry to be the grinch, but I'm not sure this shall happen by
> default. For example, Tramp is built-in in Emacs, and it exists also as
> GNU ELPA package. Many people don't use it; why shall they be forced to
> upgrade?

They asked for a list of _possible_ upgrades; they can then unmark
packages they don't want to upgrade.

It might help if there was a mechanism to freeze packages, so no
upgrades are suggested for packages that are frozen.

> And, as said otherwere already, such an upgraded Emacs is different
> from an Emacs started via "emacs -Q". For Tramp, it is essential to
> analyze problems with an Emacs started as "emacs -Q". We would loose
> this possiblitiy.

Actually, it is essential for the user reporting a problem and the
maintainer diagnosing it to be using the same versions; that's normal
for ELPA packages. It requires all relevant details in the bug
report, and ways to start emacs with the relevant versions; -Q may do
that, but for ELPA packages it needs to be followed by loading the
relevant packages.

-- 
-- Stephe

Re: Bundling GNU ELPA packages with Emacs - what are we missing?

[Stefan Monnier]

> It might help if there was a mechanism to freeze packages, so no
> upgrades are suggested for packages that are frozen.

There's a mechanism to control which version of a package is used
(i.e. `package-load-list`).  We could/should refrain from auto-updating
package whose version is "frozen" this way.

Note that the purpose of `package-load-list` is not to prevent
installing other versions, but to prevent *activating* other versions.


        Stefan

Re: Bundling GNU ELPA packages with Emacs - what are we missing?

[Andy Moreton]

On Thu 10 Sep 2020, Stefan Monnier wrote:

>> It might help if there was a mechanism to freeze packages, so no
>> upgrades are suggested for packages that are frozen.
>
> There's a mechanism to control which version of a package is used
> (i.e. `package-load-list`).  We could/should refrain from auto-updating
> package whose version is "frozen" this way.
>
> Note that the purpose of `package-load-list` is not to prevent
> installing other versions, but to prevent *activating* other versions.

The term "activate" is used many times wrt packages, but is not
defined anywhere. How are users meant to understand what it means ?

    AndyM

Re: Bundling GNU ELPA packages with Emacs - what are we missing?

[Stefan Monnier]

> The term "activate" is used many times wrt packages, but is not
> defined anywhere. How are users meant to understand what it means ?

It means to add its files to the `load-path` and run the code indicated
by the autoload cookies (i.e. mostly setup some autoloads, potentially
add itself to some menu, or things like that).

Usually, for major modes it's the only thing necessary for the
major mode to be automatically used on the appropriate files.

Package.el does it in `package-activate-all` (also called by
`package-initialize`, tho it depends on some details, for historical
reasons).


        Stefan

Re: Bundling GNU ELPA packages with Emacs - what are we missing?

[Andy Moreton]

On Thu 10 Sep 2020, Stefan Monnier wrote:

>> The term "activate" is used many times wrt packages, but is not
>> defined anywhere. How are users meant to understand what it means ?
>
> It means to add its files to the `load-path` and run the code indicated
> by the autoload cookies (i.e. mostly setup some autoloads, potentially
> add itself to some menu, or things like that).
>
> Usually, for major modes it's the only thing necessary for the
> major mode to be automatically used on the appropriate files.
>
> Package.el does it in `package-activate-all` (also called by
> `package-initialize`, tho it depends on some details, for historical
> reasons).

A clear explanation - thanks. The problem however is that this term is
not defined in package.el or in the manual. The doc string for
`package-activate' does not describe what activate means in this
context, leaving readers none the wiser.

Please add this description to package.el and to the manual.

    AndyM