linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Vegard Nossum <vegard.nossum@oracle.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Akira Yokosawa <akiyks@gmail.com>
Cc: linux-doc@vger.kernel.org, Mauro Carvalho Chehab <mchehab@kernel.org>
Subject: Re: docs: requirements.txt has stopped working again
Date: Tue, 23 Jan 2024 09:19:55 -0700	[thread overview]
Message-ID: <874jf4m384.fsf@meer.lwn.net> (raw)
In-Reply-To: <2018acaa-a6ce-4074-b3e1-1a12018573fb@oracle.com>

Vegard Nossum <vegard.nossum@oracle.com> writes:

> It makes sense when those ancient versions build our docs just fine and
> run MUCH faster too. Here was my proposal, more specifically:
>
> 1) requirements.txt : take out all the version constraints so it will
> just use the latest versions of everything (unless there are issues with
> those) -- this is what I think Akira/Jon/you really want

Yes, this is what I would do.

> 2) requirements-2.4.4.txt : create this file and add and freeze ALL the
> sphinx dependencies at specific versions that make 2.4.4 work --
> freezing everything means we should never really need to touch this file
> again

I don't believe you'll ever get to a point where it never breaks; that's
a *lot* of dependencies to track down.

I don't think it's worth it.  The number of people who *really* want to
build with a 2.4.4 system is, I believe, quite small; they may all be
copied on this email.  It is enough of a niche thing at this point that,
I think, we should not go to great lengths to support it.  Perhaps
somebody can contribute a document for folks who really want to do it.

> 3) add a warning when building using slow sphinx versions, perhaps
> encouraging people with these slow versions to use
> requirements-2.4.4.txt with a virtualenv.
>
> I think this ticks all the boxes:
>
> - No more whack-a-mole (since requirements.txt would have no bounds to
> update, and requirements-2.4.4.txt would have everything frozen)
>
> - Doesn't raise the minimum version unnecessarily for people who would
> still like to use the older and faster version.

I'm happy to not break 2.4.4 for now, though I suspect that day may
come.  But I think directing people toward such an old version is not
going to lead to long-term joy; for better or for worse, Sphinx has
moved on.

jon

  reply	other threads:[~2024-01-23 16:19 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 [this message]
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
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=874jf4m384.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=akiyks@gmail.com \
    --cc=jani.nikula@linux.intel.com \
    --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).