Currently, it's possible to break our test suite by having an env var
set that influences uv, either a `UV_*` var, or something more generic
such as the XDG env vars. We previously fixed them env-var-by-env-var as
we discovered. By clearing uv-specific env var for subcommands, we can
invert this.
We intentionally avoid clearing all env vars as some of them, especially
on Windows, are system env vars required for basic operations.
Notable limitations are that this only affects tests that use
`TestContext::add_shared_env` (default, can be opted-out).
Fixed#9873
<!--
Thank you for contributing to uv! To help us out with reviewing, please
consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title?
- Does this pull request include references to any relevant issues?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
This allows users to set the HTTP, HTTPS, and no proxy variables via the
configuration files like ~pyproject.toml~ and uv.toml.
Users can set like so:
`uv.toml`
```toml
https-proxy = "http://my_cool_proxy:10500"
http-proxy = "http://my_cool_proxy:10500"
no-proxy = [
"dontproxyme.com",
"localhost",
]
```
Resolves https://github.com/astral-sh/uv/issues/9472
## Test Plan
<!-- How was it tested? -->
It also adds a new integration test for the proxy support in
`uv-client`.
This was tested on some of our developer machines with our proxy setup
using `~/.config/uv/uv.toml` with values like:
```toml
https-proxy = "http://my_cool_proxy:10500"
http-proxy = "http://my_cool_proxy:10500"
no-proxy = [
"dontproxyme.com",
"localhost",
]
```
---------
Signed-off-by: Eli Uriegas <eliuriegas@meta.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
Part of https://github.com/astral-sh/uv/issues/4392
We shouldn't link to PyPI, and dropping the workspace-level
documentation link should mean that we get the auto-generated `docs.rs`
links.
## Summary
Adds the version for environment variables added in
https://github.com/astral-sh/uv/pull/16040 and
https://github.com/astral-sh/uv/pull/16125. as these were in-flight
before documentation versioning was added.
Adds ability to emit a compiler error when added in is missing for
improved reporting to the developer.
e.g. example for the ones fixed in this PR
```shell
error: missing #[attr_added_in("x.y.z")] on `UV_UPLOAD_HTTP_TIMEOUT`
note: env vars for an upcoming release should be annotated with `#[attr_added_in("next release")]`
--> crates\uv-static\src\env_vars.rs:593:15
|
593 | pub const UV_UPLOAD_HTTP_TIMEOUT: &'static str = "UV_UPLOAD_HTTP_TIMEOUT";
| ^^^^^^^^^^^^^^^^^^^^^^
error: missing #[attr_added_in("x.y.z")] on `UV_WORKING_DIRECTORY`
note: env vars for an upcoming release should be annotated with `#[attr_added_in("next release")]`
--> crates\uv-static\src\env_vars.rs:1087:15
|
1087 | pub const UV_WORKING_DIRECTORY: &'static str = "UV_WORKING_DIRECTORY";
| ^^^^^^^^^^^^^^^^^^^^
error: could not compile `uv-static` (lib) due to 2 previous errors
```
## Summary
As new environment variables get introduced (e.g. `UV_EDITABLE`) I
thought it would useful to start tracking which release they were
introduced. I think its a common workflow to navigate to the [env var
documentation](https://docs.astral.sh/uv/reference/environment) to know
what the env var for something is but then end up in a situation where
one is using an environment variable with the wrong version of uv and
not notice immediately that its not compatible and therefore ignored.
## Test Plan
Existing tests.
The versions in `since` have all been manually reviewed to the best of
my ability for correctness.
Following a CI failure in https://github.com/astral-sh/uv/pull/15028,
ensure that all workspace crates are inheriting the MSRV and other
workspace configuration from the workspace root.
## Summary
Resolves#8417
I've just begun learning procedural macros, so this PR is more of a
proof of concept. It's still a work in progress, and I welcome any
assistance or feedback.
As per
https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html
Before that, there were 91 separate integration tests binary.
(As discussed on Discord — I've done the `uv` crate, there's still a few
more commits coming before this is mergeable, and I want to see how it
performs in CI and locally).