GNU bug report logs - #65649
[PATCH] package-vc: Continue installing package when documentation build fails

Previous Next

Full log

Message #26 received at 65649 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Joseph Turner <joseph <at> breatheoutbreathe.in>
Cc: 65649 <at> debbugs.gnu.org
Subject: Re: bug#65649: [PATCH] package-vc: Continue installing package when
 documentation build fails
Date: Fri, 01 Sep 2023 13:14:45 +0000

Joseph Turner <joseph <at> breatheoutbreathe.in> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Btw, watch out when reporting a bug, you shouldn't CC people directly,
>> but add a X-Debbugs-CC header
>> (https://debbugs.gnu.org/Reporting.html#xcc), as otherwise I'd be
>> creating a new bug report when responding to your message.
>
> Good to know! Thank you! Is it okay to CC people when responding to a
> bug report email (e.g. if I CC'd Eli in this email)?

Yes, as soon as one is sending a message to [bugnumber]@debbugs.gnu.org,
everything is fine.  The issue if you Cc me directly, is that if I don't
watch out, I'll send my response to bug-gnu-emacs <at> gnu.org, and thus
create a new bug.

>> Joseph Turner <joseph <at> breatheoutbreathe.in> writes:
>>
>>> It would be nice to report more information about the package with failed
>>> documentation, but AFAICT with-demoted-errors does not allow its FORMAT
>>> string to be a symbol whose value is a string.
>>
>> What are the main errors we are concerned with?  I am a bit concerned
>> that `with-demoted-errors' is a too coarse approach and might be applied
>> to widely in your current patch.  It might be better to use a classical
>> condition-case and handle the right errors in the right place, or if
>> practicable try to detect if an error would occur before doing anything.
>
> I don't know what kinds of errors to expect, which is why I went with
> the coarse approach.  Under what circumstances would we want to stop
> package installation entirely when documentation can't be built?

I am not sure we want that behaviour at all actually.  Just because
there is a typo in the documentation, doesn't mean the package is
unusable.  The user should be able to install the package, be notified
about the error -- if the have the time, they can fix it and send the
maintainer a patch resolving the issue for everyone.  Likewise, if the
user updates a package, it wouldn't make sense to ignore everything or
worse still revert the update due to a small mistake in the
documentation file.

>> Also, the buffer *package-vc doc* should stay persistent and would
>> include error messages, that could also be used here.
>
> Like this?
>
> (with-demoted-errors "package-vc: Could not build documentation. See *package-vc doc* for details" ... )

Yes, that is what I had in mind.

Joseph Turner <joseph <at> breatheoutbreathe.in> writes:

> Joseph Turner <joseph <at> breatheoutbreathe.in> writes:
>
>> Philip Kaludercic <philipk <at> posteo.net> writes:
>>
>>> Also, the buffer *package-vc doc* should stay persistent and would
>>> include error messages, that could also be used here.
>>
>> Like this?
>>
>> (with-demoted-errors "package-vc: Could not build documentation. See *package-vc doc* for details" ... )
>
> Actually, that would not have handled the error related to relative org
> #+include statements, since that error happened above this line:
>
> (with-current-buffer (get-buffer-create " *package-vc doc*")

There is no reason why we cannot already create and use the buffer
earlier, to log org-related bugs.  One has to be careful when emptying
the buffer, but it might make sense to have a separate buffer for each
package, especially when updating multiple packages at once...

Previous Next

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