question about recent change

question about recent change

[Tom Tromey]

I saw this go in:

    * lisp/emacs-lisp/package.el: New "external" package status
    
    An external package is any installed package that's not built-in
    and not from `package-user-dir', which usually means it's from an
    entry in `package-directory-list'.  They are treated much like
    built-in packages, in that they cannot be through the Package Menu
    deleted and are not considered for upgrades.

It seems to me that it makes sense to upgrade such packages.
The upgraded package can be installed in the user's directory.

This scenario was always a goal of package.el -- to let some packages
ship with Emacs or in the distro, and then to let users install new
versions themselves by when convenient.

It wasn't clear to me from the commit if this ability still exists.

Tom

Re: question about recent change

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

> It seems to me that it makes sense to upgrade such packages.
> The upgraded package can be installed in the user's directory.

They won't be automatically marked for upgrade when typing U, but they can
still be upgraded.
If the user marks a newer version for installation from one of the Elpas
it'll install just fine, and from that point on it will be marked for
upgrades like any other package.

> This scenario was always a goal of package.el -- to let some packages
> ship with Emacs or in the distro, and then to let users install new
> versions themselves by when convenient.
>
> It wasn't clear to me from the commit if this ability still exists.

Yes, the message should be more clear. These external packages are being
treated the same way as built-in packages have always been treated. This
means that (1) the user can indeed install a newer version if desired, and
(2) as long as they don't install a newer version it won't be automatically
upgraded.

Do you think these external packages should instead be automatically marked
for upgrade?
I think it makes sense for them to be treated the same as built-in packages.

[-- Attachment #2: Type: text/html, Size: 1298 bytes --]

Re: question about recent change

[Tom Tromey]

>>>>> "Artur" == Artur Malabarba <bruce.connor.am@gmail.com> writes:

Artur> Do you think these external packages should instead be
Artur> automatically marked for upgrade?  I think it makes sense for
Artur> them to be treated the same as built-in packages.

I tend to think that any sort of package should be available for
upgrade.

If it is available externally as well, then it presumably has its own
releases and users might reasonably want to know that.

Tom

Re: question about recent change

[Dmitry Gutov]

On 05/08/2015 10:33 PM, Tom Tromey wrote:

> I tend to think that any sort of package should be available for
> upgrade.

If they are, I won't be able to put into package-directory-list the git 
checkouts of the packages I develop.

Re: question about recent change

[Tom Tromey]

>>>>> "Dmitry" == Dmitry Gutov <dgutov@yandex.ru> writes:

Dmitry> On 05/08/2015 10:33 PM, Tom Tromey wrote:
>> I tend to think that any sort of package should be available for
>> upgrade.

Dmitry> If they are, I won't be able to put into package-directory-list the
Dmitry> git checkouts of the packages I develop.

You don't have to upgrade.

I strongly believe that package.el should first serve the needs of
ordinary users.  Power users like you can roll their own, or add a
special power-user-only feature to package.el, or etc.

Tom

Re: question about recent change

[Dmitry Gutov]

On 05/08/2015 11:51 PM, Tom Tromey wrote:

> You don't have to upgrade.

So, I'll have to avoid pressing U, or undo the marks for particular 
packages every time?

> I strongly believe that package.el should first serve the needs of
> ordinary users.  Power users like you can roll their own, or add a
> special power-user-only feature to package.el, or etc.

What will be the most popular circumstances, until which an ordinary 
user will have a non-built-in package outside of package-user-dir?

If they have been installed by the operating system, the latter probably 
expects to manage their upgrades as well (for instance, to match the 
installed elisp version to the version of the command-line program it is 
used with).

Re: question about recent change

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

>> I tend to think that any sort of package should be available for
>> upgrade.
>
> If they are, I won't be able to put into package-directory-list the git
checkouts of the packages I develop.

If we change external and built-in packages to be automatically upgraded by
default, we can always add yet another directory variable for packages that
are not to be upgraded.

[-- Attachment #2: Type: text/html, Size: 438 bytes --]

Re: question about recent change

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

> Artur> Do you think these external packages should instead be
> Artur> automatically marked for upgrade?  I think it makes sense for
> Artur> them to be treated the same as built-in packages.
>
> I tend to think that any sort of package should be available for
> upgrade.

It's certainly available. The question is whether we want built-in packages
to be upgraded by default. I'm fine either way.

> If it is available externally as well, then it presumably has its own
> releases and users might reasonably want to know that.

Either way, they'll be shown the available releases on the menu.

[-- Attachment #2: Type: text/html, Size: 740 bytes --]

Re: question about recent change

[Stefan Monnier]

Artur> Do you think these external packages should instead be
Artur> automatically marked for upgrade?  I think it makes sense for
Artur> them to be treated the same as built-in packages.
> I tend to think that any sort of package should be available for
> upgrade.

As explained, they are.

> If it is available externally as well, then it presumably has its own
> releases and users might reasonably want to know that.

I have a feeling you're misunderstanding "external".  All it means is
that these packages have been installed elsewhere.  Two typical
scenarios:
- those "external" packages are actually installed system-wide by the
  sysadmin (or by dpkg, tho IIUC Debian's packaging does make use of
  this (yet)).  They're plain normal ELPA packages, probably installed
  using package.el as well, but by another user and into
  a special directory.  And the user can expect that the sysadmin will
  be in charge of keeping them up-to-date.
- those external packages are the elpa/packages subdirectories.  So they
  also correspond to packages available in ELPA.  And here again, the
  expectation is that those packages will be updated "some other way"
  (e.g. by "git pull").

I think the important message is that the normal "update all" command
should only be used to *replace* packages.  It's important that we
support installing a second version of a package without removing the
older version, but this should be a special use-case which only happens
by explicit request from the user.


        Stefan