Recreate venv for each build + install from pylock.toml when available - #345
Conversation
| venv_path, | ||
| symlinks=os.name != "nt", | ||
| with_pip=True, | ||
| clear=True, |
There was a problem hiding this comment.
This ensures a fresh venv.
| symlinks=os.name != "nt", | ||
| with_pip=True, | ||
| clear=True, | ||
| upgrade_deps=True, |
There was a problem hiding this comment.
Upgrade pip, because otherwise we use the bundled pip, and we need at least 25.1 for pylock.toml support.
Could do this just for the pylock.toml part, but might as well update for both.
There was a problem hiding this comment.
Just a little clarification for anyone reading this in the future, it needs 26.1 for pylock.toml support.
ZeroIntensity
left a comment
There was a problem hiding this comment.
I'm definitely not the most qualified reviewer here, but nothing jumps out at me as wrong (and I really want the highlighting 😃)
|
You'll be happy to hear that Discourse (which uses highlight.js) will also get |
|
Hugo, do you realize I was the one who implemented that 😅: highlightjs/highlight.js#4398 But yeah, I think GitHub uses hljs too. Hopefully we see adoption before the 3.15 release. |
|
|
||
| So we can reuse them from builds to builds, while they contain | ||
| different Sphinx versions. | ||
| The venv is recreated from scratch for every build: pip considers |
There was a problem hiding this comment.
We'll now be build[ing]_venv[s] for every version, but also every language. That's quite a lot considering the amount of translations we have. I'd rather avoid the rebuilds, I think running it once per version will keep the venv fresh enough?
There was a problem hiding this comment.
Yes, good idea, updated to create each venv at most once per run.
It also now deletes the venvs at the end of the run, we don't need to keep those hanging around, especially as they're recreated at the start of a run.
How does it look now?
Co-authored-by: Stan Ulbrych <stan@python.org>
Co-authored-by: Stan Ulbrych <stan@python.org>
|
Our Integration Test currently runs on |
I don't think we tried it before, it was added last year: #275. No objection, let's see how it goes. |
|
I'll write a patch. |
|
I've confirmed this is creating new venv dirs for 3.13-3.16, like docsbuild@docs:/srv/docsbuild$ du -sh venv*
32M venv
299M venv-3.10
297M venv-3.11
294M venv-3.12
299M venv-3.13
299M venv-3.14
299M venv-3.15
300M venv-3.15-only-html-en
299M venv-3.16And then tidying up afterwards: docsbuild@docs:/srv/docsbuild$ du -sh venv*
32M venv
299M venv-3.10
297M venv-3.11
294M venv-3.12
299M venv-3.13
299M venv-3.14
299M venv-3.15
299M venv-3.16I've moved |
|
Translations also working: https://docs.python.org/pl/3.16/whatsnew/3.15.html#whatsnew315-lazy-imports I've now deleted all the old |
Re: python/cpython#153227 (comment)
python/cpython#153228 switched to use a dev version of pygments from GitHub, but it's not being picked up on the doc server.
This is because:
pip install --upgrade -rrequirements.txtstill sees pygments with the same version number in the venv, so doesn't need to upgrade itThis PR does two things:
pylock.tomlwhen when available.