linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Akira Yokosawa <akiyks@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Vegard Nossum <vegard.nossum@oracle.com>
Cc: linux-doc@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Akira Yokosawa <akiyks@gmail.com>
Subject: Re: docs: requirements.txt has stopped working again
Date: Tue, 23 Jan 2024 18:53:59 +0200	[thread overview]
Message-ID: <87y1cgm1nc.fsf@intel.com> (raw)
In-Reply-To: <cb72b3d6-de7a-4c8a-a99c-72d58a23f89c@gmail.com>

On Tue, 23 Jan 2024, Akira Yokosawa <akiyks@gmail.com> wrote:
> Hi all,
>
> Annoyingly, installing Sphinx 2.4.4 using requirements.txt of v6.8-rc1
> ends up in a run-time error which looks similar to the one Vegard
> reported in commit f4cac0f74658 ("Documentation: constrain alabaster
> package to older versions").
>
> The new error is from sphinxcontrib.applehelp which reads:
>
>     Sphinx version error:
>     The sphinxcontrib.applehelp extension used by this project needs
>     at least Sphinx v5.0; it therefore cannot be built with this version.
>
> Do we want to continue whack-a-mole update for Sphinx 2.4.4?

I looked into the root cause here. Sphinx since early versions
(predating even 2.4.4) depends on packages such as

- sphinxcontrib-applehelp
- sphinxcontrib-devhelp
- sphinxcontrib-htmlhelp
- sphinxcontrib-qthelp
- sphinxcontrib-serializinghtml

but does so without any version constraints. Recently, all of those
*packages* started first depending on Sphinx >= 5. Apparently this
prevented installation of incompatible combos, but resulted in circular
dependency issues in pip.

To fix the circular dependencies, all of those *packages* made the
dependency on Sphinx >= 5 optional, but made the *extensions* in them
app.require_sphinx('5.0') runtime. This happened in the past two weeks.

What this means is that installing any Sphinx < 5 succeeds, it'll pull
in the latest versions of the above mentioned packages because they meet
the package dependencies, but all of them will fail runtime for any
Sphinx version before 5.0. Even if we don't actually use or need any of
those extensions.

I ran git blame and git tag --contains on them to figure out the
packages compatible with Sphinx < 5. These should do it:

diff --git a/Documentation/sphinx/requirements.txt b/Documentation/sphinx/requirements.txt
index 5d47ed443949..0aa4fdb84632 100644
--- a/Documentation/sphinx/requirements.txt
+++ b/Documentation/sphinx/requirements.txt
@@ -2,5 +2,10 @@
 jinja2<3.1
 # alabaster>=0.7.14 is not compatible with Sphinx<=3.3
 alabaster<0.7.14
+sphinxcontrib-applehelp==1.0.4
+sphinxcontrib-devhelp==1.0.2
+sphinxcontrib-htmlhelp==2.0.1
+sphinxcontrib-qthelp==1.0.3
+sphinxcontrib-serializinghtml==1.1.5
 Sphinx==2.4.4
 pyyaml

Conclusions:

- Distro packages probably work, because they maintain deps separately.

- Installing latest from pip probably works. There may be occasional
  hiccups, but they'll likely get noticed and fixed quickly.

- Installing known good requirements from pip freeze works.

- Installing some random version from pip is likely to fail.

- Installing a mix of distro and pip packages is likely to fail.

So maybe we'll need a minimum Sphinx version for distro packages, and
three separate requirements. One with just the top level deps (sphinx
and pyyaml, no versions specified), one which is basically a pip freeze
of that with know good config, updated regularly, and then a pip freeze
of the conservative (2.4.4?) versions, rarely updated.


BR,
Jani.


-- 
Jani Nikula, Intel

  parent reply	other threads:[~2024-01-23 16:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23  4:14 docs: requirements.txt has stopped working again Akira Yokosawa
2024-01-23  7:43 ` Vegard Nossum
2024-01-23 12:30   ` Jani Nikula
2024-01-23 13:21     ` Vegard Nossum
2024-01-23 16:19       ` Jonathan Corbet
2024-01-24 15:02       ` Akira Yokosawa
2024-01-24 15:25         ` Jonathan Corbet
2024-01-24 15:43           ` Akira Yokosawa
2024-01-26 14:42             ` Akira Yokosawa
2024-01-24 19:56         ` Vegard Nossum
2024-01-23 16:53 ` Jani Nikula [this message]
2024-01-23 18:11   ` Jani Nikula

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=87y1cgm1nc.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=akiyks@gmail.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=vegard.nossum@oracle.com \
    /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;
as well as URLs for NNTP newsgroup(s).