[PATCH 3 of 6] scripts: docs-headings: set HGRCPATH to empty

[Thomas De Schampheleire]

El dom., 30 dic. 2018 a las 1:13, Mads Kiilerich
(<mads at kiilerich.com>) escribió:
>
> On 12/29/18 10:50 PM, Thomas De Schampheleire wrote:
> > # HG changeset patch
> > # User Thomas De Schampheleire <thomas.de_schampheleire at nokia.com>
> > # Date 1546111044 -3600
> > #      Sat Dec 29 20:17:24 2018 +0100
> > # Node ID 60672272cef36dd45594b607036fb5d7eda5b15c
> > # Parent  a7df630cfe21e5e66c555b9fa88ef2c3930870b1
> > scripts: docs-headings: set HGRCPATH to empty
> >
> > User settings could pollute output, for example in my case, within a
> > virtualenv I get the following on every 'hg' invocation:
> >
> > *** failed to import extension absorb from
> > /home/tdescham/repo/contrib/hg-experimental/installed/lib64/python2.7/site-packages/hgext3rd/absorb:
> > 'module' object has no attribute 'command'
>
>
> It seems quite rare to have such problems that can be fixed by setting
> HGRCPATH, and where doing it doesn't cause other problems. It doesn't
> seem like a general problem or solution.
>
> It seems like it would be a better solution to solve it in your setup,
> perhaps by setting HGRCPATH in the virtualenv "activate" script. That
> will be closer to fixing the root cause, and allow you to run hg from
> the virtualenv command prompt.

I'm fine with keeping the script as it was.
But generally, at work, we noticed potential harmful influence of
user's hgrc files on tools/scripts that call hg. Users could have
hooks that shouldn't fire for the script, or settings that change
output. HGPLAIN alone doesn't cover everything. So, clearing HGRCPATH
is a standard thing we do.

>
> (But also, this command could also just use a glob to find files to
> process, and leave it to the user to run `hg diff` manually to see what
> actually changed. That seems like a better solution than polishing the
> hg invocation ... and would also avoid the question of whether we should
> set HGPLAIN.)

Could be done, but it would no longer allow returning an error code if
something changed.
But that could be handled as follows: instead of writing to the real
file, write to a separate file, e.g. foo.rst.fixed and call 'diff'
rather than 'hg diff'.
Optionally the script could write in-place.

But since the number of callers of this script is so low, I wouldn't
call it a priority. It does what it has to do, and after the speed
optimization it's off of my hitlist :-)

/Thomas