GNU bug report logs - #78844
30.1; feature request: public interface for querying builtin packages and versions

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Xiyue Deng <manphiz <at> gmail.com>
Cc: 78844 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, spwhitton <at> spwhitton.name
Subject: bug#78844: 30.1; feature request: public interface for querying builtin packages and versions
Date: Sat, 28 Jun 2025 13:38:12 +0300

> From: Xiyue Deng <manphiz <at> gmail.com>
> Cc: spwhitton <at> spwhitton.name, 78844 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Sat, 28 Jun 2025 01:29:15 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Xiyue Deng <manphiz <at> gmail.com>
> >> Cc: spwhitton <at> spwhitton.name, 78844 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> >> Date: Fri, 27 Jun 2025 17:25:41 -0700
> >> 
> >> >> I don't seem to find any Elisp manual for package.el (there is one in
> >> >> the Emacs manual but only has documents for user facing interfaces for
> >> >> the package buffer).  But do let me know if there is.
> >> >
> >> > There's the "Packaging" chapter in the ELisp manual.  Whether it is a
> >> > suitable place to add these interfaces depends on who is the intended
> >> > audience of the interfaces.  If that chapter is not suitable, maybe
> >> > the "Loading" chapter is a better place.
> >> >
> >> 
> >> Admittedly I tried to be lazy and want to just add the new functions to
> >> an existing section but didn't find any good fit.  I just bit the bullet
> >> and added a new section in package.texi for these functions.  Please
> >> help proofread.
> >
> > Thanks, comments below.  However, packages.texi is not the right place
> > for this stuff, because it's for the user manual, not for the ELisp
> > reference manual.  Since these APIs are for Lisp programmers, they
> > should be documented in the ELisp manual, and the chapters I mentioned
> > are in that manual.
> >
> 
> I'm a bit confused: the file I changed was doc/lispref/package.texi,
> which I suppose is the ELisp manual, no?

Sorry, my bad.  Ignore that part of my review comments.

> >> To be precise, package--builtin-versions doesn't have all the built-in
> >> packages (which I think is a subset of the list populated by
> >> package--builtins).  As here we are more interested in packages that do
> >> have a version associated, I have renamed the function to
> >> `package-versioned-builtin-packages' to hopefully better convey the
> >> intention.  Let me know if this is desirable.
> >
> > The renaming could be fine if the intended users of this API will
> > indeed only want to know about versioned built-in packages, and won't
> > care about those who have no versions.  Is that in fact true?  If so,
> > why aren't unversioned packages important?
> >
> > If we do want to return the built-in packages that have no versions,
> > then the name should remain as it was, and we should instead amend the
> > implementation to also return packages that have no versions.
> >
> 
> The motivation for introducing those functions is to be able to check
> whether a built-in package has higher version compared to the same
> package in other packaging system, which, in my case, is Debian's APT,
> and could be useful for other packaging systems.  See my first mail[1]
> for a concrete motivating example and my reply[2] to Stefan's email for
> a more explanations.

OK, but that is a special case.  Other callers might want the list
regardless of whether the packages have a version, no?  Limiting the
usefulness only to packages that have a version sounds like a serious
limitation to me.

> The current status quo is that most Emacs addons that are packaged in
> Debian are in `package--builtin-versions', so this is sufficient for our
> use case.  Plus, on testing I realized that `package--builtins' is not
> populated by default until one loads `finder-inf', which means increased
> loading time to use that information.

I understand that it is easier to implement based on
package--builtin-versions, but we should first decide whether this
limitation is significant enough to justify a more complex
implementation.

I hope Stefan and others will chime in about this aspect.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.