mirror of
https://github.com/astral-sh/uv.git
synced 2025-11-18 19:21:46 +00:00
- Adds a collapsible section for the project concept - Splits the project concept document into several child documents. - Moves the workspace and dependencies documents to under the project section - Adds a mkdocs plugin for redirects, so links to the moved documents still work I attempted to make the minimum required changes to the contents of the documents here. There is a lot of room for improvement on the content of each new child document. For review purposes, I want to do that work separately. I'd prefer if the review focused on this structure and idea rather than the content of the files. I expect to do this to other documentation pages that would otherwise be very nested. The project concept landing page and nav (collapsed by default) looks like this now: <img width="1507" alt="Screenshot 2024-11-14 at 11 28 45 AM" src="https://github.com/user-attachments/assets/88288b09-8463-49d4-84ba-ee27144b62a5">
58 lines
1.9 KiB
Markdown
58 lines
1.9 KiB
Markdown
# Locking and syncing
|
|
|
|
### Creating the lockfile
|
|
|
|
The lockfile is created and updated during uv invocations that use the project environment, i.e.,
|
|
`uv sync` and `uv run`. The lockfile may also be explicitly created or updated using `uv lock`:
|
|
|
|
```console
|
|
$ uv lock
|
|
```
|
|
|
|
### Exporting the lockfile
|
|
|
|
If you need to integrate uv with other tools or workflows, you can export `uv.lock` to
|
|
`requirements.txt` format with `uv export --format requirements-txt`. The generated
|
|
`requirements.txt` file can then be installed via `uv pip install`, or with other tools like `pip`.
|
|
|
|
In general, we recommend against using both a `uv.lock` and a `requirements.txt` file. If you find
|
|
yourself exporting a `uv.lock` file, consider opening an issue to discuss your use case.
|
|
|
|
### Checking if the lockfile is up-to-date
|
|
|
|
To avoid updating the lockfile during `uv sync` and `uv run` invocations, use the `--frozen` flag.
|
|
|
|
To avoid updating the environment during `uv run` invocations, use the `--no-sync` flag.
|
|
|
|
To assert the lockfile matches the project metadata, use the `--locked` flag. If the lockfile is not
|
|
up-to-date, an error will be raised instead of updating the lockfile.
|
|
|
|
### Upgrading locked package versions
|
|
|
|
By default, uv will prefer the locked versions of packages when running `uv sync` and `uv lock`.
|
|
Package versions will only change if the project's dependency constraints exclude the previous,
|
|
locked version.
|
|
|
|
To upgrade all packages:
|
|
|
|
```console
|
|
$ uv lock --upgrade
|
|
```
|
|
|
|
To upgrade a single package to the latest version, while retaining the locked versions of all other
|
|
packages:
|
|
|
|
```console
|
|
$ uv lock --upgrade-package <package>
|
|
```
|
|
|
|
To upgrade a single package to a specific version:
|
|
|
|
```console
|
|
$ uv lock --upgrade-package <package>==<version>
|
|
```
|
|
|
|
!!! note
|
|
|
|
In all cases, upgrades are limited to the project's dependency constraints. For example, if the
|
|
project defines an upper bound for a package then an upgrade will not go beyond that version.
|