A downside of how I currently have it is that it need the entire docs job to finish (i.e. it includes waiting for the doc tests), we could have it run earlier by moving it under the docs job (though I don't think that is particularly nice), however since it runs in 7 seconds I think it is a negligible issue.

@webknjaz could you please take a peek at this?

Should this new job also be required by "All required checks pass"?

Terry asked me to not make it required on the issue.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

include the docs with Python.

Some Linux distributions do (often not installed by default, as is done with IDLE), but, Terry, I don't quite understand what you want to achieve with this check?
Problems are best caught before they make it into prod (i.e. checking PRs), if we compare against the released copy it seems a bit late for that?

For the check, I think the best option is moving copy_strip() out from the standard library, otherwise we cannot use the latest version in the step (further on that point, currently it is unusable if installed, since paths are relative to it).

I asked about docs and installations because if Python were always installed with a frozen local (and up to date) copy of all the docs, as I believe the case on Windows and mac, installed IDLE would not need a separate copy (possibly not up to date) of its file. But that seems not the case, so help.html is needed even after installation.

@terryjreedy sounds like a chance to collaborate with distro packages and figure it out together?

cc @befeleme @hroncok @mgorny could you shed the light on the downstream handling of the IDLE packaging? It should be possible to make python3.x-idle (Fedora) and dev-lang/python:3.x w/ the USE-flag tk (Gentoo) include the HTML file from docs, right?

Sorry, I don't understand what I'm being asked here. We install whatever make altinstall installs, which includes idlelib/help.html.

Same here. If we can regenerate that HTML during the build, even better, but not mandatory.

(Assuming the source HTML file from Doc is actually built by Sphinx, we will probably avoid building it and ship what is there.)

@mgorny @hroncok my understanding is that currently there's Doc/library/idle.rst in the repo which is the ultimate source. It gets built with Sphinx into an HTML file (Doc/build/html/library/idle.html, one of many). This HTML file eventually ends up on docs.python.org.

However, additionally, a human makes a slightly reduced copy of that file, puts it into Lib/idlelib/help.html and commits it into the CPython repo, effectively hardcoding a certain state of this HTML file (I think this bit is prone to human error). Then it gets installed through downstream-specific mechanisms (e.g. dnf install python3) and those mechanisms don't go through the pipeline of building the Sphinx docs.

Now, Doc/build/html/library/idle.html and Lib/idlelib/help.html are close enough so theoretically, it should be possible to get rid of the Lib/idlelib/help.html copy and make IDLE use the one from the docs.

What people here don't know is whether it'd be difficult/a burden for downstreams to handle such a migration. Some non-Linux installers bundle the docs and so "install python" for such users results in the docs being available so IDLE could rely on that w/o issues. But since downstreams typically separate the docs into standalone packages, it's not clear if it's possible to package things in a way that, for example, dnf install python3.x-idle would rely on Sphinx-built docs.

Does this make the context more clear? Would it make your lives more difficult downstream if Lib/idlelib/help.html was removed from the repo and a Sphinx docs build was required to get it included?

What people here don't know is whether it'd be difficult/a burden for downstreams to handle such a migration. Some non-Linux installers bundle the docs and so "install python" for such users results in the docs being available so IDLE could rely on that w/o issues. But since downstreams typically separate the docs into standalone packages, it's not clear if it's possible to package things in a way that, for example, dnf install python3.x-idle would rely on Sphinx-built docs.

That would be difficult/a burden for for Fedora. Namely because:

• We build and ship python3.15-idle, python3.14-idle, python3.13-idle... but we only build one version of the Python documentation. If idle would gain a dependency on the built docs, we would need to build the docs for all the versions (and that would likely require multiple sphinx versions etc.).
• We build the documentation as a standalone package, indeed, so it would create a dependency loop that would require a boostrapping procedure.

Does this make the context more clear? Would it make your lives more difficult downstream if Lib/idlelib/help.html was removed from the repo and a Sphinx docs build was required to get it included?

My understanding of this PR was that Lib/idlelib/help.html would be kept in the repo (and the source tarball) but a CI job would assert it is up to date. If it were removed, it would certainly be a problem.

Yes, it would definitely be a problem for Gentoo as well. We support installing docs for multiple Python versions but:

1. I don't really see how IDLE would be able to determine the correct documentation install directory, and since the documentation directory path contains exact package revision, it's not guaranteed to be stable. We'd effectively have to "patch" the path somehow into every Python build and force new Python builds if we ever need to bump docs (unlikely but technically possible).
2. We're using the prebuilt documentation archives, and AFAIK these are not available for prereleases.
3. A lot of users are actually concerned about disk space use (to the point that we had to move test to a separate package), and I'm pretty sure they won't like having to install the whole docs because idle happens to be installed.

This PR is stale because it has been open for 30 days with no activity.

Closing, we need to decide what it is we want.