mirror of
https://github.com/certbot/certbot.git
synced 2026-05-22 10:20:52 -04:00
00a51ab22b
It's a [drop-in replacement](https://docs.astral.sh/uv/pip/compatibility/) that speeds things up. I don't see any reason why not. `--use-pep517` is [set by default]( https://docs.astral.sh/uv/pip/compatibility/#pep-517-build-isolation), so we don't need it. `--disable-pip-version-check` also does nothing on uv. `uv` [uses separate](https://docs.astral.sh/uv/pip/compatibility/#build-constraints) `UV_BUILD_CONSTRAINT` and `UV_CONSTRAINT`. I just added it to both to do the simplest thing here. We could split them. We probably don't actually need to pipstrap pip anymore, I could take that out. What's happening with `parsedatetime` and `python-digitalocean` is that they were always secretly wrong. Since `pip` compiles bytecode by default, it was suppressing the errors. If you add the `--compile-bytecode` flag to `uv`, it passes, but I don't think we should do that. You can see the failure happen on main by passing `--no-compile` to the pip args and running `certbot -r -e oldest`. Now what I don't understand is that some places seem to say the `'\/'` error from `parsedatetime` only started in python 3.12, whereas others see it on earlier python. Perhaps pytest is vendorizing python or something. Not too worried about that, needed to get updated anyway, and it's an accurate oldest version based on our oldest OSes. `python-digitalocean` is techincally newer than debian 11, but we've made that decision before so it seems fine to me. |
||
|---|---|---|
| .. | ||
| docker | ||
| pinning | ||
| snap | ||
| _release.sh | ||
| extract_changelog.py | ||
| finish_release.py | ||
| oldest_constraints.txt | ||
| pip_install.py | ||
| pipstrap.py | ||
| release.sh | ||
| requirements.txt | ||
| retry.sh | ||
| sphinx-quickstart.sh | ||
| venv.py | ||