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

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

Re: package-vc-install fails to build docs


From: Philip Kaludercic
Subject: Re: package-vc-install fails to build docs
Date: Sun, 23 Apr 2023 18:36:59 +0000

Joseph Turner <joseph@breatheoutbreathe.in> writes:

> What would be the first steps to support :make in package-vc?

If you are interested in working on this, I would take a look at
`package-vc--unpack-1' which would probably be the best place for that.

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Joseph Turner <joseph@breatheoutbreathe.in> writes:
>>
>>> Thank you Ruijie Yu and Philip Kaludercic for your help!
>>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Ruijie Yu via Users list for the GNU Emacs text editor
>>>> <help-gnu-emacs@gnu.org> writes:
>>>>> I'm looking at the package-vc source code, and it doesn't seem to try to
>>>>> autodetect any doc files at the moment.  Try adding `:doc` in your
>>>>> `package-vc-install' call and see if anything changes.
>>>
>>> Actually, it looks like extra plist elements like :doc are stripped away
>>> in package-vc--unpack. package-vc--unpack doesn't pass its pkg-spec arg
>>> along to package-vc--unpack-1. package-vc--unpack-1 then calls
>>> package-vc--desc->spec, which gets the spec anew from ELPA IIUC.
>>>
>>> Regardless, I believe the issue lies elsewhere, see below.
>
> How shall we pass :doc and :make values from package-vc-install down to
> package-vc--build-documentation?
>
> Do we want to refactor package-vc-unpack-1 so that it accepts a pkg-spec
> argument? Or maybe add :doc an :make keys to the pkg-desc plist?

:doc is passed via an argument, and :make would have to be handled
before.

>> You are right (and I totally missed the :make entry in the specification
>> above).  Package-vc did intentionally NOT add :make or :shell-command
>> support, for the sake of user safety.  It wouldn't be difficult to
>> implement this, if we could find a way to make it reasonably safe
>> (e.g. if the user has to opt-in or we trust package specifications if
>> they were delivered by a trusted package archive).
>
> How about yes-or-no-p by default, with an customization option to
> automatically trust specs from a trusted package archive?

The latter should work fine, but the first would only be possible in
interactive usage.

-- 
Philip Kaludercic



reply via email to

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