unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Philip Kaludercic <philipk@posteo.net>
To: Okamsn <okamsn@protonmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
Subject: Re: How to install documentation in sub-directory with Package VC?
Date: Wed, 05 Apr 2023 07:30:46 +0000	[thread overview]
Message-ID: <87bkk29461.fsf@posteo.net> (raw)
In-Reply-To: <e05442cf-daef-140c-c5dd-5944e65bbaec@protonmail.com> (okamsn@protonmail.com's message of "Sun, 02 Apr 2023 00:41:43 +0000")

Okamsn <okamsn@protonmail.com> writes:

>>> +@example
>>> +@group
>>> +(package-vc-install 'csv-mode)
>>> +@end group
>>> +@end example
>>> +
>>> +The second way is to specify this information manually in the first
>>> +argument of @code{package-vc-install}, in the form of
>>> +@samp{(@var{name} . @var{spec})}.  @var{spec} should be a property
>>> +list using any of the following keys:
>>> +
>>> +@itemize @bullet
>>> +@item @code{:url}
>>> +A URL specifying the repository from which to fetch the package's
>>> +source code.
>>> +
>>> +@item @code{:branch}
>>> +The name of the branch to checkout after cloning the directory.
>>
>> At the risk of being pedantic, we check out the right branch /while/
>> cloning, not /after/ cloning and I don't know if that matters.  (I also
>> just now noticed that I used the same phrasing in the documentation
>> string for `package-vc-selected-packages').
>
> I tried to do as Eli Zaretskii asked and changed it to be less Git
> specific.  Does it still convey what you want?

I think it is fine now.  Thanks.

[...]

> From 0024726c24f16976f1b472afe8e079e5892517b5 Mon Sep 17 00:00:00 2001
> From: Earl Hyatt <okamsn@protonmail.com>
> Date: Mon, 27 Mar 2023 20:57:31 -0400
> Subject: [PATCH] Add more documentation for the keys of
>  `package-vc-selected-packages`.
>
> * doc/emacs/package.texi (Specifying Package Sources): List the
>   accepted keys in a new subsection of Fetching Package Sources.
>
> * lisp/emacs-lisp/package-vc.el (package-vc-selected-packages):
>   - Mention the `:doc` key.  Add the `:doc` key to the Customize form.
>   - Mention the new Info node.
>   - Correct "TexInfo" to "Texinfo".
>   - Avoid Git-specific terms for the description of `:branch`.
>   - Mention guessing `:vc-backend` based on the URL.
> ---
>  doc/emacs/package.texi        | 77 +++++++++++++++++++++++++++++++++++
>  lisp/emacs-lisp/package-vc.el | 25 ++++++++----
>  2 files changed, 93 insertions(+), 9 deletions(-)
>
> diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
> index 7a2bc11d03c..7ad4143d3cb 100644
> --- a/doc/emacs/package.texi
> +++ b/doc/emacs/package.texi
> @@ -578,3 +578,80 @@ Fetching Package Sources
>  and initializes the code.  Note that you might have to use
>  @code{package-vc-refresh} to repeat the initialization and update the
>  autoloads.
> +
> +@subsection Specifying Package Sources
> +@cindex package specification
> +@cindex specification, for source packages
> +
> +  To install a package from source, Emacs must know where to get the
> +package's source code (such as a code repository) and basic
> +information about the structure of the code (such as the main file in
> +a multi-file package).  These things are described by a package's
                                 ^
                                 a bit informal?  I think you can just
                                 drop the word and still convey the same
                                 information.
> +@dfn{specification}.
> +
> +  When supported by a package archive (@pxref{Package
> +Archives,,,elisp, The Emacs Lisp Reference Manual}), Emacs can
> +automatically download a package's specification from said archive.

Not sure if this might be confusing.  package-vc has heuristics to try
and guess how to install a package, so it is /possible/ but not
/reliable/ to install a package from a third-party archive like MELPA.
Then again, perhaps we don't have to mention that at all in the manual,
so as to not promote an unreliable trick.

> +If the first argument passed to @code{package-vc-install} is a symbol
> +naming a package, then Emacs will use the specification provided by
> +the archive for that package.
> +
> +@example
> +@group
> +;; Emacs will download BBDB's specification from GNU ELPA:
> +(package-vc-install 'bbdb)
> +@end group
> +@end example
> +
> +  A package's specification can also be given manually as the first
> +argument to @code{package-vc-install}.  This allows you to install
> +source packages from locations other than the known archives listed in
> +the user option @code{package-archives}.  A package specification is a
> +list of the form @code{(@var{name} . @var{spec})}, in which @var{spec}
> +should be a property list using any of the following keys.
>
> +For definitions of basic terms for working with code repositories and
> +version control systems, see @xref{VCS Concepts,,,emacs, The GNU Emacs
> +Manual}.

Should this paragraph be moved down below the table?  Otherwise the "any
of the following" reads funnily.

> +@table @code
> +@item :url
> +A string containing the URL that specifies the repository from which
> +to fetch the package's source code.
> +
> +@item :branch
> +A string containing the revision of the code to install.  This is not
> +to be confused with a package's version number.
> +
> +@item :lisp-dir
> +A string containing the repository-relative name of the directory to
> +use for loading the Lisp sources, which defaults to the root directory
> +of the repository.
> +
> +@item :main-file
> +A string containing the main file of the project, from which to gather
> +package metadata.  If not given, the default is the package name with
> +".el" appended to it.

(This is true most of the time, but if you check out what
`package-vc--main-file' does, then you will see that this is not
necessary.  Again, I don't think this implementation detail is worth
documenting publicly.)

> +@item :doc
> +A string containing the repository-relative name of the documentation
> +file from which to build an Info file.  This can be a Texinfo file or
> +an Org file.
> +
> +@item :vc-backend
> +A symbol naming the VC backend to use for downloading a copy of the
> +package's repository (@pxref{Version Control Systems,,,emacs, The GNU
> +Emacs Manual}).  If omitted, a guess will be made based on the
> +provided URL, or, failing that, the process will fall back onto the
> +value of @code{package-vc-default-backend}.
> +@end table
> +
> +@example
> +@group
> +;; Specifying information manually:
> +(package-vc-install
> +  '(bbdb :url "https://git.savannah.nongnu.org/git/bbdb.git"
> +         :lisp-dir "lisp"
> +         :doc "doc/bbdb.texi"))
> +@end group
> +@end example
> diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el
> index 253b35f1f1a..cbc9a1ecece 100644
> --- a/lisp/emacs-lisp/package-vc.el
> +++ b/lisp/emacs-lisp/package-vc.el
> @@ -152,25 +152,31 @@ package-vc-selected-packages
>        The URL of the repository used to fetch the package source.
>  
>     `:branch' (string)
> -      If given, the name of the branch to checkout after cloning the directory.
> +      The repository-specific revision of the code to install.
> +      This is not to be confused with a package's version number.
>  
>     `:lisp-dir' (string)
>        The repository-relative name of the directory to use for loading the Lisp
> -      sources.  If not given, the value defaults to the root directory
> -      of the repository.
> +      sources, which defaults to the root directory of the repository.
>  
>     `:main-file' (string)
>        The main file of the project, relevant to gather package metadata.
> -      If not given, the assumed default is the package name with \".el\"
> +      If not given, the default is the package name with \".el\"
>        appended to it.
>  
> +   `:doc' (string)
> +      The documentation file from which to build an Info file.
> +      This can be a Texinfo file or an Org file.
> +
>     `:vc-backend' (symbol)
> -      A symbol of the VC backend to use for cloning the package.  The
> -      value ought to be a member of `vc-handled-backends'.  If omitted,
> -      `vc-clone' will fall back onto the archive default or on
> -      `package-vc-default-backend'.
> +      A symbol of the VC backend to use for cloning the package.
> +      The value ought to be a member of `vc-handled-backends'.
> +      If omitted, a guess will be made based on the provided URL,
> +      or, failing that, `vc-clone' will fall back onto the
> +      archive default or on `package-vc-default-backend'.
>
> -  All other keys are ignored.
> +  All other keys are ignored.  Package specifications are further
> +  described in the Info node `(emacs)Fetching Package Sources'.

I believe I mentioned this before, but what do you think about just
linking to the manual, and not duplicating the information here and
there?  It would make maintenance easier, but might not be nice for
users on systems that do not come installed with documentation like
Debian...  Then again, this wouldn't be the only place where this would
affect users.

>  This user option will be automatically updated to store package
>  specifications for packages that are not specified in any
> @@ -184,6 +190,7 @@ package-vc-selected-packages
>                                           (:branch string)
>                                           (:lisp-dir string)
>                                           (:main-file string)
> +                                         (:doc string)
>                                           (:vc-backend symbol)))))
>    :version "29.1")



  parent reply	other threads:[~2023-04-05  7:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14  3:13 How to install documentation in sub-directory with Package VC? Okamsn
2023-03-14 15:56 ` Philip Kaludercic
2023-03-15  9:41   ` Philip Kaludercic
2023-03-16  1:37     ` Okamsn
2023-03-16  8:44       ` Philip Kaludercic
2023-03-28  1:50         ` Okamsn
2023-03-28  7:41           ` Philip Kaludercic
2023-04-02  0:41             ` Okamsn
2023-04-02  5:24               ` Eli Zaretskii
2023-04-05  7:30               ` Philip Kaludercic [this message]
2023-04-06  3:52                 ` Okamsn
2023-04-06 15:42                   ` Philip Kaludercic
2023-04-10 13:39                     ` Philip Kaludercic
2023-04-12  0:04                       ` Okamsn
2023-04-12  7:27                         ` Philip Kaludercic
2023-04-12  7:41                           ` Eli Zaretskii
2023-04-12  7:48                             ` Philip Kaludercic
2023-04-07 21:46             ` Jonas Bernoulli
2023-04-08  8:36               ` Philip Kaludercic
2023-04-09 18:39                 ` Jonas Bernoulli
2023-04-09 20:44                   ` Lynn Winebarger
2023-04-09 21:55                   ` Philip Kaludercic
2023-03-28 11:48           ` Eli Zaretskii

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=87bkk29461.fsf@posteo.net \
    --to=philipk@posteo.net \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=okamsn@protonmail.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).