ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Randy Dunlap <rdunlap@infradead.org>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	ksummit@lists.linux.dev,
	Linux Documentation <linux-doc@vger.kernel.org>,
	Akira Yokosawa <akiyks@gmail.com>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [TECH TOPIC] Kernel documentation - update and future directions
Date: Wed, 03 Sep 2025 13:25:18 +0300	[thread overview]
Message-ID: <9a9d8e15947e7f11c92d390bb221ebc6e601212e@intel.com> (raw)
In-Reply-To: <20250903120409.32f3b3b0@foz.lan>

On Wed, 03 Sep 2025, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Em Wed, 03 Sep 2025 10:47:28 +0300
> Jani Nikula <jani.nikula@intel.com> escreveu:
>
>> On Tue, 02 Sep 2025, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>> > I'm with Jon here, I wouldn't blindly override the Python interpreter
>> > selected by the user. What we could however do is print a message if we
>> > detect a version of Python that could improve performance, telling the
>> > user they could switch.  
>> 
>> Just piling on here, totally agreed.
>> 
>> Don't surprise the user. Let the user be in control. If they choose a
>> silly combo, let them. You know, they might be debugging the issues in
>> that silly combo to begin with, and don't want to jump through hoops to
>> work around tools that think they know better.
>> 
>> Letting the user know they're using a silly combo and suggesting better
>> alternatives is a whole different matter.
>
> The code can be changed to suggest a better alternative, and having an
> optional argument to load the newest one automatically, but the issue
> still remains:
>
> if one has native python3.6, for instance, and he installed a newer one
> to build htmldocs with:
>
> 	dnf install -y python3.11 # or zypper/apt-get/urpmi/... install python3.11
>
> python3 will still be a soft link to python3.5, and all attempts to
> build docs will fail.

If the user wants to shoot themselves in the foot, let them.

> With the approach I'm taken, Makefile will call sphinx-pre-install
> and sphinx-build-wrapper. They both use a function that checks for
> incompatible versions, re-running the code with one which works,
> warning the user about that. So, on openSUSE leap, for instance, 
> we have two official packages with Sphinx:
>
> 	$ grep PRETTY_NAME /etc/os-release 
> 	PRETTY_NAME="openSUSE Leap 15.6"
>
> 	$ zypper search sphinx |grep -E "python\S+\-Sphinx "
> 	   | python3-Sphinx                          | Python documentation generator                                              | package
> 	i+ | python311-Sphinx                        | Python documentation generator                                              | package
>
>
> There, python3-Sphinx is too old:
>
> 	# sphinx-build --version
> 	sphinx-build 2.3.1
>
> As docs minimal requirement is 3.4.3. Also, it is based on python3.6,
> which is not compatible with the kernel Sphinx extensions.
>
> Which the approach I took, once one installs python311-Sphinx like I did,
> the build happens cleanly:
>
> 	$ make htmldocs
> 	# sphinx-pre-install, which checks is needed packages are installed
> 	Python 3.6.15 not supported. Changing to /usr/bin/python3.11
> 	# sphinx-build-wrapper, which calls Sphinx to build the docs
> 	Python version: 3.11.9
> 	Python 3.6.15 not supported. Changing to /usr/bin/python3.11
> 	Python version: 3.11.9
> 	Using alabaster theme
> 	Using Python kernel-doc
> 	...
>
> but if we remove the switch logic:
>
>         -print(f"Python {python_ver} not supported. Changing to {new_python_cmd}")
>         -
>         -try:
>         -    os.execv(new_python_cmd, args)
>         -except OSError as e:
>         -    sys.exit(f"Failed to restart with {new_python_cmd}: {e}")
>         -
> 	+print(f"Python {python_ver} not supported.")
>
> The build will then fail:
>
> 	# make htmldocs
> 	Python 3.6.15 not supported.
> 	Python 3.6.15 not supported.
> 	Traceback (most recent call last):
> 	  File "/usr/bin/sphinx-build", line 5, in <module>
> 	    from sphinx.cmd.build import main
> 	ModuleNotFoundError: No module named 'sphinx'
>
> because:
>
> - python3.6 is not supported;
> - sphinx-build is installed with python311-Sphinx, which also installed
>   python311 package.
>
> See, in this case, the user wanted docs build to use python3.11, as
> it installed python311-Sphinx package from a distro official package.
>
> Without the version-check logic, the only option would be for the user
> to do:
>
> 	ln -sf python3 python3.11  # or something equivalent
>
> -
>
> Btw, the same type of packaging multiple versions of python and 
> Sphinx is quite common on several distributions. This is not
> an issue specific to openSUSE.
>
> Also, notice that we're talking here about building docs with
> distros that are using a 9+ years old python3, e.g.:
>
> 	- openSUSE Leap;
> 	- RHEL8-based distros;
> 	- other old LTS and EOL distros that have a too old Python 
> 	  versions.
>
> Thanks,
> Mauro

-- 
Jani Nikula, Intel

  reply	other threads:[~2025-09-03 10:25 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22 22:55 Jonathan Corbet
2025-08-25 10:35 ` Mauro Carvalho Chehab
2025-08-28 23:01 ` Laurent Pinchart
2025-08-30 13:37   ` Jonathan Corbet
2025-08-30 16:00     ` Vegard Nossum
2025-08-30 22:23       ` Laurent Pinchart
2025-08-30 23:08         ` Jonathan Corbet
2025-08-31 14:03           ` Mauro Carvalho Chehab
2025-08-31 20:16             ` Jonathan Corbet
2025-09-01  6:17               ` Randy Dunlap
2025-09-01 19:27                 ` Mauro Carvalho Chehab
2025-09-01 10:09             ` Jani Nikula
2025-09-01 16:51               ` Randy Dunlap
2025-09-01 17:52                 ` Mark Brown
2025-09-01 18:15                   ` Randy Dunlap
2025-09-01 18:20                     ` Mark Brown
2025-09-01 18:25                   ` Jonathan Corbet
2025-09-01 18:40                     ` Mark Brown
2025-09-01 19:51                       ` Jonathan Corbet
2025-09-01 22:52                       ` Mauro Carvalho Chehab
2025-09-01 18:46                   ` Mauro Carvalho Chehab
2025-09-01 18:52                     ` Mark Brown
2025-09-01 22:56                       ` Mauro Carvalho Chehab
2025-09-02 11:15                         ` Mark Brown
2025-09-02 11:59                           ` Mauro Carvalho Chehab
2025-09-02 12:14                             ` Mauro Carvalho Chehab
2025-09-02 13:00                               ` Mark Brown
2025-09-02 14:42                                 ` Mauro Carvalho Chehab
2025-09-02 15:15                                   ` Jonathan Corbet
2025-09-02 17:19                                     ` Mauro Carvalho Chehab
2025-09-02 18:52                                       ` Laurent Pinchart
2025-09-03  7:47                                         ` Jani Nikula
2025-09-03 10:04                                           ` Mauro Carvalho Chehab
2025-09-03 10:25                                             ` Jani Nikula [this message]
2025-09-02 18:58                                       ` Jonathan Corbet
2025-09-02 22:35                                         ` Mauro Carvalho Chehab
2025-09-03  6:29                                         ` Johannes Berg
2025-09-03 10:42                                           ` Mauro Carvalho Chehab
2025-09-03 10:45                                             ` Johannes Berg
2025-09-03 10:54                                               ` Johannes Berg
2025-09-03 14:57                                                 ` Mauro Carvalho Chehab
2025-09-03 15:07                                                   ` Laurent Pinchart
2025-09-03 15:17                                                     ` Konstantin Ryabitsev
2025-09-03 15:22                                                     ` Miguel Ojeda
2025-09-03 15:11                                                   ` Johannes Berg
2025-09-03 15:25                                                     ` Mauro Carvalho Chehab
2025-09-03 15:37                                                       ` Jonathan Corbet
2025-09-03 15:52                                                         ` Mauro Carvalho Chehab
2025-09-03 13:39                                               ` Mauro Carvalho Chehab
2025-09-03 13:51                                                 ` Laurent Pinchart
2025-09-01 19:53                     ` Jonathan Corbet
2025-09-01 23:15                       ` Mauro Carvalho Chehab
2025-09-01 18:37                 ` Mauro Carvalho Chehab
2025-09-01 19:05                   ` Andrew Lunn
2025-09-01 19:17                     ` Mark Brown
2025-09-02 10:42                 ` Jani Nikula
2025-09-02 11:55                   ` Mauro Carvalho Chehab
2025-09-02 12:07                     ` Jani Nikula
2025-09-02 15:07                       ` Mauro Carvalho Chehab
2025-09-01 18:26               ` Mauro Carvalho Chehab
2025-09-02 10:55                 ` Jani Nikula
2025-09-02 12:04                   ` Andrew Lunn

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=9a9d8e15947e7f11c92d390bb221ebc6e601212e@intel.com \
    --to=jani.nikula@intel.com \
    --cc=akiyks@gmail.com \
    --cc=bagasdotme@gmail.com \
    --cc=corbet@lwn.net \
    --cc=ksummit@lists.linux.dev \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=vegard.nossum@oracle.com \
    --cc=willy@infradead.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