Doc: Fix spurious comma in the author metadata field

[CAM-Gerlach]

Presently, there's a spurious comma in the Author metadata field as discussed in python/docs-community#40 in LaTeX, PDF, etc. docs output and visible in the corresponding BPO-5901 . This PR fixes it.

As a correlate, it might make sense to make the author metadata consistent between output formats (see, e.g. the different one for the epub builder); I can make that change here if requested.

I would think it would probably make sense to backport this to the older bugfix branches, but that's not my call.

[CAM-Gerlach]

Unfortunately, it seems that PEP editors don't have >=triage rights here, so I can't add skip issue or skip news labels for this trivial change.

[hugovk]

Labelled!

Please could you prefix the PR title (and ideally commit message) with bpo-5901?

That should get the bots to link them up.

Thanks!

[ned-deily]

Thanks for the PR. Let's wait 24 hours and check the daily docs build output before closing the bpo issue.

[ned-deily]

The latest PDFs look good so I've closed bpo-5901. Thanks!

[CAM-Gerlach]

Please could you prefix the PR title (and ideally commit message) with bpo-5901?

I would have, but it is only tangentially related to that issue and I didn't want to close it, and also the great GH migration was in progress

Thanks for the PR. Let's wait 24 hours and check the daily docs build output before closing the bpo issue.

Is there any plan to move them to CD and trigger a rebuild/deploy when changes are made? I seem to recall something like that being discussed.

[ned-deily]

Thanks for the PR. Let's wait 24 hours and check the daily docs build output before closing the bpo issue.

Is there any plan to move them to CD and trigger a rebuild/deploy when changes are made? I seem to recall something like that being discussed.

The EN version of the on-line docs, and their downloadable formats, for feature and bugfix branches are rebuilt and published every 3 hours. The translated versions are rebuilt every 24 hours. I'm not aware of any plans to change that at the moment; right now the docs build server is kept quite busy trying to stick to that schedule primarily because the downloadable formats take a long time to produce (compared with just the html web pages), there are three active branches (main->3.11, 3.10, 3.9 and for part of the annual release cycle there is usually a fourth branch in the mix), and there are now multiple translations for each branch. That's a lot of building.

[hugovk]

We do have a zip of the docs available as a download from the CI, which is useful but a hosted version would be ideal.

#82041 is the issue.

Netlify was tested but we were limited to 1000 build minutes per month, or about 170 builds before they started charging.

#15288

There's another attempt to use put PR builds as subdirs on GitHub Pages, but that's stalled due the 1GB limit and needing a way to clear out old builds (plus I'm not so sure about so much churn on a single git branch).

#19025

Another suggestion, more promising, use GHA to build docs, and then upload to Netlify.

#82041 (comment)

And perhaps we could use ReadTheDocs for previews, like in the PEPs repo.

[CAM-Gerlach]

Netlify was tested but we were limited to 1000 build minutes per month, or about 170 builds before they started charging.

Maybe the PSF infra people could talk to them about some sort of arrangement; I don't think it would be that expensive in the grand scheme of things, and some sort of official sponsorship arrangement could help defray that.

There's another attempt to use put PR builds as subdirs on GitHub Pages, but that's stalled due the 1GB limit and needing a way to clear out old builds (plus I'm not so sure about so much churn on a single git branch).

A couple of years ago I used GHP to temporarily host a continuously updated website with real-time data from a remote sensor. As I recall, both from their docs and experience, they would start throttling at around 10 rebuilds per hour, and (while I obviously didn't test this), and trying to go too much above that for too long would allegedly result in a stern email from GitHub support and potentially more serious consequences. Even well below that its quiet slow and kludgdy, especially because with multiple asynchronous builds, you can't just reset-commit each result, you're stuck with an ever-growing commit history forever, unless you take it offline and reset it.

We ended up just getting a cheap $5/mo. DigitalOcean VPS, sticking Apache on it and rsyncing the site there instead, and its vastly better in every way. If worst comes to worse, something like that is always an option; you could just have GHA rsync the built site to a PR-named subdir there, and since GHA is doing the heavy lifting and there's relatively minimal inbound requests (just people checking the previews), one VPS can basically host effectively unlimited preview builds

Another suggestion, more promising, use GHA to build docs, and then upload to Netlify.

This indeed sounds like the most promising of the lot; combining the generous limits, power and ease of use of GHA with the convenience of preview site hosting. I'm not familiar with uploading content to Netlify externally, but I'm assuming that's fairly straightforward.

And perhaps we could use ReadTheDocs for previews, like in the PEPs repo.

Since RTD is already used as the backend and/or for previews elsewhere, this seems like the simplest and most obvious solution. On the other hand, as we've discussed previously on the PEPs repo, I was somewhat disappointed by its performance, several times slower than GHA and its poor build UI/feedback, though it seemed there were ways to mitigate a good amount of that.

[hugovk]

Maybe the PSF infra people could talk to them about some sort of arrangement; I don't think it would be that expensive in the grand scheme of things, and some sort of official sponsorship arrangement could help defray that.

Indeed, I wonder how many minutes the open-source projects at https://www.netlify.com/open-source/ use.

But GHA build+Netlify deploy is a worth a shot first. I'll ping the issue.

Re: RTD performance, I've finally opened readthedocs/readthedocs.org#9118 as a first step.