bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot


From: Eli Zaretskii
Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot
Date: Wed, 12 Apr 2023 15:30:20 +0300

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: João Távora <joaotavora@gmail.com>,
>   monnier@iro.umontreal.ca,
>   62720@debbugs.gnu.org,  larsi@gnus.org
> Date: Wed, 12 Apr 2023 12:00:09 +0000
> 
> > Yes, if Philip and Stefan don't object.  But, since there will be a
> > command for updating core packages, doesn't this go against your
> > desire not to change the UX?
> 
> After thinking about this for a bit, I think that the right approach is
> to use package-install instead of writing a separate command.  After
> all, this will make the behaviour of package-install consistent with
> that of the package menu.

Is this for master or for the release branch?

And I thought we all agreed built-in packages need special treatment
anyway, didn't we?  Then why having a separate command is not a
natural next step?

> It might work but it should be tested somewhat thoroughly before the
> patch is applied.  In the meantime, I just finished a similar approach
> that does not modify `package-installed-p', but just adds another
> utility function:

A new utility function is fine by me, even if this is e branch.  But I
don't quite understand how this is supposed to work in package-install
to allow updating built-in packages, and do that in a way that will
not touch the existing code for non-built-in packages in significant
ways (assuming you propose this from the release branch).  Can you
elaborate on that?

> +(defun package-core-p (package)
> +  "Return non-nil the built-in version of PACKAGE is loaded."

Didn't you say the "core" terminology was confusing people?

> +  (let ((package (if (package-desc-p package)
> +                     (package-desc-name package)
> +                   package)))
> +    (and (assq package (package--alist))
> +         (package-built-in-p package))))

It sounds like this doesn't check whether a package is "core", it
checks whether it's built-in and can be updated?  So maybe the name
should be changed to reflect that?  And the doc string as well (what
it means by "is loaded")?

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]