These are regression tests for #6269, #6412 and #6836. In this commit,
their test outputs are all wrong. We'll update these snapshots after
fixing the underlying bug by refactoring how `requires-python`
simplification works.
- Respect `UV_PROJECT_ENVIRONMENT` when in project root
- Add `--no-project` and `--no-workspace` to opt-out of above and
`requires-python` detection
- Rename `[NAME]` to `[PATH]` in CLI
Allows configuration of the (currently hard-coded) path to the virtual
environment in projects using the `UV_PROJECT_ENVIRONMENT` environment
variable.
If empty, we'll ignore it. If a relative path, it will be resolved
relative to the workspace root. If an absolute path, we'll use that.
This feature targets use in Docker images and CI. The variable is
intended to be set once in an isolated system and used for all uv
operations.
We do not expose a CLI option or configuration file setting — we may
pursue those later but I see them as lower priority. I think a
system-level environment variable addresses the most pressing use-cases
here.
This doesn't special-case the system environment. Which means that you
can use this to write to the system Python environment. I would
generally strongly recommend against doing so. The insightful comment
from @edmorley at
https://github.com/astral-sh/uv/issues/5229#issuecomment-2312702902
provides some context on why. More generally, `uv sync` will remove
packages from the environment by default. This means that if the system
environment contains any packages relevant to the operation of the
system (that are not dependencies of your project), `uv sync` will break
it. I'd only use this in Docker or CI, if anywhere. Virtual environments
have lots of benefits, and it's only [one line to "activate"
them](https://docs.astral.sh/uv/guides/integration/docker/#using-the-environment).
If you are considering using this feature to use Docker bind mounts for
developing in containers, I would highly recommend reading our [Docker
container development
documentation](https://docs.astral.sh/uv/guides/integration/docker/#developing-in-a-container)
first. If the solutions there do not work for you, please open an issue
describing your use-case and why.
We do not read `VIRTUAL_ENV` and do not have plans to at this time.
Reading `VIRTUAL_ENV` is high-risk, because users can easily leave an
environment active and use the uv project interface today. Reading
`VIRTUAL_ENV` would be a breaking change. Additionally, uv is
intentionally moving away from the concept of "active environments" and
I don't think syncing to an "active" environment is the right behavior
while managing projects. I plan to add a warning if `VIRTUAL_ENV` is
set, to avoid confusion in this area (see
https://github.com/astral-sh/uv/pull/6864).
This does not directly enable centrally managed virtual environments. If
you set `UV_PROJECT_ENVIRONMENT` to an absolute path and use it across
multiple projects, they will clobber each other's environments. However,
you could use this with something like `direnv` to achieve "centrally
managed" environments. I intend to build a prototype of this eventually.
See #1495 for more details on this use-case.
Lots of discussion about this feature in:
- https://github.com/astral-sh/rye/issues/371
- https://github.com/astral-sh/rye/pull/1222
- https://github.com/astral-sh/rye/issues/1211
- https://github.com/astral-sh/uv/issues/5229
- https://github.com/astral-sh/uv/issues/6669
- https://github.com/astral-sh/uv/issues/6612
Follow-ups:
- #6835
- https://github.com/astral-sh/uv/pull/6864
- Document this in the project concept documentation (can probably
re-use some of this post)
Closes https://github.com/astral-sh/uv/issues/6669
Closes https://github.com/astral-sh/uv/issues/5229
Closes https://github.com/astral-sh/uv/issues/6612
## Summary
Http headers are supposed to be case-insensitive (RFC 2616), but there
are some implementations that don't normalize them.
I noticed it while migrating to `uv`, calls to an internal registry
failed. A man in the middle server helped me to find that `pip` uses
Title-Case while `uv pip` uses lowercase.
## Test Plan
I tested `uv` with the same server and now it works fine.
## Summary
Update the extended docker example to use bind mounts and avoid creating
extra layers and avoid copying files into layers
This is in line with the official Docker templates for Python
applications (you can try them out using `docker init`. I found them
very helpful!)
## Summary
Closes https://github.com/astral-sh/uv/issues/5610
This PR introduces additional images with the uv/uvx binaries from
scratch for both amd64/arm64 and make the mapping easy to configure by
generating the Dockerfile on the fly. This approach focuses on
minimizing CI time by taking advantage of dedicating a worker per
mapping (20-30s~ per job).
This PR also fixes `org.opencontainers.image.version` for all tags
(including the one from `scratch) to contain the right release version
instead of branch name `main` (default when no tag patterns are
specified).
For example, on release `x.y.z`, this will publish the following image
tags with format `ghcr.io/astral-sh/uv:{tag}` with manifests for both
amd64/arm64. This also include `x.y` tags for each respective additional
tag.
* From **scratch**: `latest`, `x.y.z`, `x.y` (currently being published)
* From **alpine:3.20**: `alpine`, `alpine3.20`, `x.y.z-alpine`,
`x.y.z-alpine3.20`
* From **debian:bookworm-slim**: `debian-slim`, `bookworm-slim`,
`x.y.z-debian-slim`, `x.y.z-bookworm-slim`
* From **buildpack-deps:bookworm**: `debian`, `bookworm`,
`x.y.z-debian`, `x.y.z-bookworm`
* From **python:3.12-alpine**: `python3.12-alpine`,
`x.y.z-python3.12-alpine`
* From **python:3.11-alpine**: `python3.11-alpine`,
`x.y.z-python3.11-alpine`
* From **python:3.10-alpine**: `python3.10-alpine`,
`x.y.z-python3.10-alpine`
* From **python:3.9-alpine**: `python3.9-alpine`,
`x.y.z-python3.9-alpine`
* From **python:3.8-alpine**: `python3.8-alpine`,
`x.y.z-python3.8-alpine`
* From **python:3.12-bookworm**: `python3.12-bookworm`,
`x.y.z-python3.12-bookworm`
* From **python:3.11-bookworm**: `python3.11-bookworm`,
`x.y.z-python3.11-bookworm`
* From **python:3.10-bookworm**: `python3.10-bookworm`,
`x.y.z-python3.10-bookworm`
* From **python:3.9-bookworm**: `python3.9-bookworm`,
`x.y.z-python3.9-bookworm`
* From **python:3.8-bookworm**: `python3.8-bookworm`,
`x.y.z-python3.8-bookworm`
* From **python:3.12-slim-bookworm**: `python3.12-slim-bookworm`,
`x.y.z-python3.12-slim-bookworm`
* From **python:3.11-slim-bookworm**: `python3.11-slim-bookworm`,
`x.y.z-python3.11-slim-bookworm`
* From **python:3.10-slim-bookworm**: `python3.10-slim-bookworm`,
`x.y.z-python3.10-slim-bookworm`
* From **python:3.9-slim-bookworm**: `python3.9-slim-bookworm`,
`x.y.z-python3.9-slim-bookworm`
* From **python:3.8-slim-bookworm**: `python3.8-slim-bookworm`,
`x.y.z-python3.8-slim-bookworm`
<!--
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
Separate exceptions for different timeouts to make it easier to debug
issues like #6105.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
Not tested at all.
## Summary
Closes#6319.
## Test Plan
I tested with `file:///mirror`, `file://localhost/mirror`, and
`http://mirror` to confirm that it was working as expected.
``` shell-session
/private/tmp/mirror-local 07:08:18
:) tree mirror
mirror/
└── 20240814/
└── cpython-3.12.5+20240814-aarch64-apple-darwin-install_only_stripped.tar.gz
```
<img width="626" alt="image"
src="https://github.com/user-attachments/assets/9c04224d-305c-47ee-a524-4a6abeb79da4">
## Summary
Right now, we have slightly different `requires-python` semantics for
`-p 3.11` vs. `-p 3.11 --universal`, and slightly different (wrong)
semantics for how we compare against the _installed_ Python version
(which doesn't ignore upper bounds, but should).
This PR rips it all out and replaces it with consistent semantics across
`uv lock`, `uv pip compile -p 3.11`, and `uv pip compile -p 3.11
--universal`. We now always ignore upper bounds.
Closes https://github.com/astral-sh/uv/issues/6859.
Closes https://github.com/astral-sh/uv/issues/5045.
Forward an error for missing temp directories:
```
$ env TMPDIR=.tmp uv-debug pip install httpx
error: No such file or directory (os error 2) at path "/home/konsti/projects/uv/.tmp/.tmpgIBhhh"
```
Fixes#6878
## Summary
A few of these should use `absolute` instead of `canonicalize`; and
apparently we no longer need to strip the `CANONICAL_CWD` to get tests
passing.
## Summary
This PR addresses an issue on Windows where `std::fs::canonicalize` can
fail or panic when resolving paths on mapped network drives. By
replacing it with `Simplified::simple_canonicalize`, we aim to improve
the robustness and cross-platform compatibility of path resolution.
### Changes
* Updated `CANONICAL_CWD` in `path.rs` to use
`Simplified::simple_canonicalize` instead of `std::fs::canonicalize`.
### Why
* `std::fs::canonicalize` has known issues with resolving paths on
mapped network drives on Windows, which can lead to panics or incorrect
path resolution.
* `Simplified::simple_canonicalize` internally uses
`dunce::canonicalize`, which handles these cases more gracefully,
ensuring better stability and reliability.
## Test Plan
Since `simple_canonicalize` has already been tested in a prior PR, this
change is expected to work without introducing any new issues. No
additional tests are necessary beyond ensuring existing tests pass,
which will confirm the correctness of the change.
## Summary
Noticed that running `cargo dev generate-all` on `main` produced changes
and saw that that the command is not run on the CI nor as a pre-commit
hook.
Not sure if having the command running as a pre-commit hook is something
we want, so I can remove it if you prefer. I find that nice to have as
it's probably easy to forget to run it, especially for new contributors
(and it will only run if there are changes in `uv_cli` or `uv_settings`
crates).
## Test Plan
- Added `cargo dev generate-all --mode check` on the CI, which produced
[this failing
job](https://github.com/astral-sh/uv/actions/runs/10648055597/job/29516699393)
- Ran `cargo dev generate-all` locally and committed the changes, which
produced [this succeeding
job](https://github.com/astral-sh/uv/actions/runs/10648076910/job/29516744942)
## Summary
- The change relates to #6635 is to include compiled python files (.pyc)
in the uv run command.
- After this change `uv run foo.pyc` should spawn `python foo.pyc`.
## Test Plan
- There is a test that uses TestContext to compile and run a simple
python file that prints "Hello World".
- I built the project locally and tried the same with a simple python
file that I had compiled.
## Summary
- Fixed the directory structure and commands for the second scenario
#6833
- Added a headline "Migrating an existing FastAPI project" because the
first part looks like a migration scenario, but didn't have its own
section before.
- Added explicit `--app` flags to commands to emphasize that the
commands create an Application project. Although maybe unnecessary
considering that `--app` is now default.
- Added instructions for testing that the dev server and Docker image
work correctly
- Took the liberty of adding a `project` at the root of all directory
structures and appropriate commands.
- With explicitly defined root directory it is easier to differentiate
between the `project` root directory and FastAPI's `app` directory.
- Without it it could be less obvious for developers less familiar with
FastAPI. Had a similar issue when started using Django several years
ago.
- If I left `app` in the command, then after copying the **app
directory** from https://github.com/astral-sh/uv-fastapi-example the
path would be `app/app/...`.
- Cleaned up glyphs in tree sctructures that were copied from FastAPI
docs.
## Caveats
- On project initialization `hello.py` is created. It is not reflected
in directory structure trees in this PR and may be slightly confusing
for developers less familiar with uv.
- I believe it will be soon addressed in #6750 and after that the docs
will reflect actual directory structure.
## Summary
Closes https://github.com/astral-sh/uv/issues/6840.
## Test Plan
```
❯ ~/workspace/uv/target/debug/uv pip list --verbose
DEBUG uv 0.4.0
DEBUG Searching for Python interpreter in system path
DEBUG Found `cpython-3.12.3-macos-aarch64-none` at `/Users/crmarsh/.local/share/rtx/installs/python/3.12.3/bin/python3` (search path)
DEBUG Using Python 3.12.3 environment at /Users/crmarsh/.local/share/rtx/installs/python/3.12.3/bin/python3
```
