public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH 02/13] docs: enable Sphinx autodoc extension to allow documenting python
Date: Thu, 15 Jan 2026 13:57:26 +0100	[thread overview]
Message-ID: <20260115135726.035fbdc8@foz.lan> (raw)
In-Reply-To: <7ed33e37aab4971cc2762ffa5ff5602856857685@intel.com>

Em Thu, 15 Jan 2026 14:18:45 +0200
Jani Nikula <jani.nikula@linux.intel.com> escreveu:

> On Thu, 15 Jan 2026, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > On Thu, Jan 15, 2026 at 12:19:48PM +0200, Jani Nikula wrote:  
> >> On Wed, 14 Jan 2026, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:  
> >> > Adding python documentation is simple with Sphinx: all we need
> >> > is to include the ext.autodoc extension and add the directories
> >> > where the Python code sits at the sys.path.
> >> >
> >> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> >> > ---
> >> >  Documentation/conf.py | 11 ++++++++---
> >> >  1 file changed, 8 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/Documentation/conf.py b/Documentation/conf.py
> >> > index 1ea2ae5c6276..429fcc9fd7f7 100644
> >> > --- a/Documentation/conf.py
> >> > +++ b/Documentation/conf.py
> >> > @@ -13,11 +13,18 @@ from  textwrap import dedent
> >> >  
> >> >  import sphinx
> >> >  
> >> > +# Location of Documentation/ directory
> >> > +doctree = os.path.abspath(".")  
> >> 
> >> Looking this up based on __file__ would be more robust than cwd.  
> >
> > Agreed.
> >  
> >> Calling this doctree is misleading because doctree is a specific Sphinx
> >> term that means something else. The doctree directory is where the
> >> parsed and pickled documents are cached.  
> >
> > Yeah, you're right: better use a different name.
> >  
> >> 
> >> Oh, I see that you're just moving this, but this is something that
> >> should be fixed first.  
> >
> > It can also be changed afterwards. Anyway, this should be on another
> > series, as such changes don't have anything to do with sphinx.ext.autodoc.
> >  
> >>   
> >> > +
> >> >  # If extensions (or modules to document with autodoc) are in another directory,
> >> >  # add these directories to sys.path here. If the directory is relative to the
> >> >  # documentation root, use os.path.abspath to make it absolute, like shown here.
> >> >  sys.path.insert(0, os.path.abspath("sphinx"))
> >> >  
> >> > +# Allow sphinx.ext.autodoc to document from tools and scripts
> >> > +sys.path.append(f"{doctree}/../tools")
> >> > +sys.path.append(f"{doctree}/../scripts")  
> >> 
> >> These would be much nicer with pathlib.Path.  
> >
> > I guess we agree to disagree here: patchlib basically overrides math divison 
> > operator to work on patches like[1]
> >
> >     p = Path('/etc')
> >     q = p / 'init.d' / 'reboot'
> >
> > This looks really weird on my eyes. I can't see why this would be better
> > than:
> >
> >     q = "/etc/init.d/reboot"
> >
> > And yeah, I've seen examples in c++ that does similar things overriding 
> > math operators to do something else. Never liked this kind of math operator
> > abuse.  
> 
> Resistance is futile, you will be assimilated. ;)

Yeah, one day I might be forced to move to it. There were much more 
assimilation attempts with regards to IPv6... So, far, I've been
resisting  ;-)

> The upside is everything's a Path object rather than a string, giving
> you methods that you'd expect paths but not strings to have, avoiding
> the tedious string manipulation all over the place.

This could make sense if this were supposed to work outside Linux 
(or Unix). As this is not the case, we don't need class abstraction
to handle directory deliminator, which is mainly the reason why 
someone writes methods and classes like os.path and pathlib.

Also, os.path has methods already to handle them in a portable way.

In this specific case, it could be using it like:

	sys.path.append(os.path.join(doctree, "/../scripts"))

to do patch contactenation, or, to be portable on other OSes:

	sys.path.append(os.path.join(doctree, "..", "scripts"))

IMO, both are easier to read, and IMHO more direct than:

	from pathlib import Path

	script_path = Path(doctree) / ".." / "scripts"
	sys.path.append(str(script_path))

Also, pathlib is more error prone, as if one does:

	>>> doctree="/tmp"
	>>> import sys
	>>> from pathlib import Path
	>>> script_path = Path(doctree) / ".." / "scripts"
	>>> sys.path.append(script_path)

It ends placing PosixPath() at the list:

	>>> sys.path
	['', '/usr/lib64/python314.zip', '/usr/lib64/python3.14', '/usr/lib64/python3.14/lib-dynload', '/usr/lib/python3.14/site-packages', PosixPath('/tmp/../scripts')]

which I don't thing it would do the right thing to do.

Regards,
Mauro

  reply	other threads:[~2026-01-15 12:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-14 13:17 [PATCH 00/13] Add kernel-doc modules to Documentation/tools Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 01/13] docs: custom.css: prevent li marker to override text Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 02/13] docs: enable Sphinx autodoc extension to allow documenting python Mauro Carvalho Chehab
2026-01-15 10:19   ` Jani Nikula
2026-01-15 11:50     ` Mauro Carvalho Chehab
2026-01-15 12:18       ` Jani Nikula
2026-01-15 12:57         ` Mauro Carvalho Chehab [this message]
2026-01-14 13:17 ` [PATCH 03/13] docs: custom.css: add CSS for python Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 04/13] docs: kdoc: latex_fonts: Improve docstrings and comments Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 05/13] docs: kdoc_files: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 06/13] docs: kdoc_item: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 07/13] docs: kdoc_parser: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 08/13] docs: kdoc_output: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 09/13] docs: kdoc_re: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 10/13] docs: kdoc: parse_data_structs: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 11/13] docs: kdoc: enrich_formatter: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 12/13] docs: kdoc: python_version: " Mauro Carvalho Chehab
2026-01-14 13:17 ` [PATCH 13/13] docs: add kernel-doc modules documentation Mauro Carvalho Chehab
2026-01-14 18:01 ` [PATCH 00/13] Add kernel-doc modules to Documentation/tools Jonathan Corbet
2026-01-14 20:20   ` Mauro Carvalho Chehab
2026-01-14 20:46     ` Jonathan Corbet
2026-01-15  1:29       ` Mauro Carvalho Chehab
2026-01-15 10:17         ` Mauro Carvalho Chehab

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

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

  git send-email \
    --in-reply-to=20260115135726.035fbdc8@foz.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=corbet@lwn.net \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=skhan@linuxfoundation.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox