unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: soliditsallgood@mailbox.org, felician.nemeth@gmail.com,
	60418@debbugs.gnu.org, stefankangas@gmail.com
Subject: bug#60418: [PATCH] Add :vc keyword to use-package
Date: Fri, 05 May 2023 17:15:42 +0000	[thread overview]
Message-ID: <87wn1mlmwx.fsf@posteo.net> (raw)
In-Reply-To: <83zg6ji806.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 May 2023 09:53:45 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: soliditsallgood@mailbox.org,  60418@debbugs.gnu.org,
>>   felician.nemeth@gmail.com,  stefankangas@gmail.com
>> Date: Fri, 05 May 2023 05:49:26 +0000
>> 
>> >> How about we just say "the commit of the latest release"?
>> >
>> > When package-vc-install is used, what is "the latest release"? isn't
>> > that the HEAD of the default branch?  IOW, what about packages that
>> > make no releases at all?
>> 
>> No, the commit of the latest release is interpreted the same way as
>> elpa-admin.el does, namely the last revision that modified the "Version"
>> header.  If no such commit can be found, then a message is printed out
>> and the installation continues under the assumption that the package is
>> using a rolling-release model.
>
> I thought package-vc-install is used (or at least can be used) to
> fetch the latest HEAD from the upstream repository?  I even thought
> this was its main raison d'être?
>
> If that's not true, does it mean we have no means for package users to
> track the latest development code of a package?

This is true, for package-vc-install, but the idea was not do this for
the :vc keyword to use-package.  My understanding is that the main
interest here is to install packages that are not available via package
archives.  And as use-package is a popular means of bootstrapping a
configuration, it seems the right approach to use the commit of the
latest revision, instead of just any commit to avoid instability.

>> >> Are there any other places where we can fix this confusion?
>> >
>> > I guess the documentation of package-vc-install shares these issues?
>> 
>> How does this sound like to you:
>> 
>> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
>> index 8f62e7d65f3..b28e33b3b89 100644
>> --- a/lisp/emacs-lisp/package-vc.el
>> +++ b/lisp/emacs-lisp/package-vc.el
>> @@ -747,11 +747,14 @@ package-vc-install
>>  symbol whose name is the package name, and the URL for the
>>  package will be taken from the package's metadata.
>>  
>> -By default, this function installs the last version of the package
>> -available from its repository, but if REV is given and non-nil, it
>> -specifies the revision to install.  If REV has the special value
>> -`:last-release' (interactively, the prefix argument), that stands
>> -for the last released version of the package.
>> +By default, this function installs the last revision of the
>> +package available from its repository, but if REV is given and
>> +non-nil, it specifies the revision to install.  If REV has the
>> +special value `:last-release' (interactively, the prefix
>> +argument), an attempt is made to find the revision of the latest
>> +release.  This is done by looking up the last revision that
>> +modified the \"Version\" header, as described in the Info
>> +node `(elisp) Library Headers'.
>
> First, too much of passive voice.
> More importantly, this still doesn't tell:
>
>   . what is "the last revision", the one installed if REV is omitted?
>   . what are possible values of REV, in addition to :last-release, and
>     how are those values interpreted, in VCS terms?

I have tried to address these issues here:

   By default, this function installs the last revision of the
   package available from its repository.  If REV is a string, it
   describes the revision to install, as interpreted by the VC
   backend.  The special value `:last-release' (interactively, the
   prefix argument), will use the commit of the latest release, if
   it exists.  The latest revision is determined by the latest
   revision to modify the \"Version\" header of the main file.

But I couldn't come up with an elegant way to avoid the passive voice in
the last sentence.

>> I can apply this or any variation thereof to emacs-29.
>
> emacs-29 is fine for documentation changes.





  reply	other threads:[~2023-05-05 17:15 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-29 18:43 bug#60418: [PATCH] Add :vc keyword to use-package Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found] ` <handler.60418.B.167238381823776.ack@debbugs.gnu.org>
2023-01-14 12:48   ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-31 14:13     ` Felician Nemeth
2023-03-31 15:38       ` Philip Kaludercic
2023-04-07 14:11         ` Philip Kaludercic
2023-04-08  8:48           ` Felician Nemeth
2023-04-08  9:06             ` Philip Kaludercic
2023-04-08  9:25               ` Felician Nemeth
2023-04-08 10:41                 ` Philip Kaludercic
2023-04-11 14:10                   ` Felician Nemeth
2023-04-12  7:12                 ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-12  7:34                   ` Philip Kaludercic
2023-04-12  9:00                     ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-16 15:43                       ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-16 16:10                         ` Eli Zaretskii
2023-04-17 19:39                           ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-18 12:13                             ` Eli Zaretskii
2023-04-19 17:38                               ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-22  9:26                                 ` Eli Zaretskii
2023-04-22 11:34                                   ` Philip Kaludercic
2023-04-23  5:51                                     ` John Wiegley
2023-04-22 11:32                                 ` Philip Kaludercic
2023-04-23  6:07                                   ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-23 12:35                                     ` Philip Kaludercic
2023-04-24 12:36                                       ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-01 19:43                                         ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-01 20:01                                           ` Philip Kaludercic
2023-05-02 13:18                                             ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-02 13:59                                               ` Robert Pluim
2023-05-02 15:09                                               ` Eli Zaretskii
2023-05-02 14:36                                             ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-02 12:40                                           ` Eli Zaretskii
2023-05-02 14:22                                             ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-02 15:16                                               ` Eli Zaretskii
2023-05-04  8:13                                                 ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-04 10:39                                                   ` Eli Zaretskii
2023-05-05  5:04                                                   ` Philip Kaludercic
2023-05-05  5:36                                                     ` Eli Zaretskii
2023-05-05  5:49                                                       ` Philip Kaludercic
2023-05-05  6:53                                                         ` Eli Zaretskii
2023-05-05 17:15                                                           ` Philip Kaludercic [this message]
2023-05-05 18:45                                                             ` Eli Zaretskii
2023-05-06 18:50                                                               ` Philip Kaludercic
2023-05-06 19:13                                                                 ` Eli Zaretskii
2023-05-07  7:34                                                                   ` Philip Kaludercic
2023-05-06 19:39                                                                 ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-07  8:52                                                                   ` Philip Kaludercic
2023-05-16 19:30                                                                     ` Philip Kaludercic
2023-05-17  5:42                                                                       ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-16 16:18                         ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wn1mlmwx.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=60418@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=felician.nemeth@gmail.com \
    --cc=soliditsallgood@mailbox.org \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).