mirror of
https://github.com/astral-sh/uv.git
synced 2025-09-14 06:25:03 +00:00

This adds `alpha`, `beta`, `rc`, `stable`, `post`, and `dev` modes to `uv version --bump`. The components that `--bump` accepts are ordered as follows: major > minor > patch > stable > alpha > beta > rc > post > dev Bumping a component "clears" all lesser component (`alpha`, `beta`, and `rc` all overwrite each other): * `--bump minor` on `1.2.3a4.post5.dev6` => `1.3.0` * `--bump alpha` on `1.2.3a4.post5.dev6` => `1.2.3a5` * `--bump dev ` on `1.2.3a4.post5.dev6` => `1.2.3a4.post5.dev7` In addition, `--bump` can now be repeated. The primary motivation of this is "bump stable version and also enter a prerelease", but it technically lets you express other things if you want them: * `--bump patch --bump alpha` on `1.2.3` => `1.2.4a1` ("bump patch version and go to alpha 1") * `--bump minor --bump patch` on `1.2.3` => `1.3.1` ("bump minor version and got to patch 1") * `--bump minor --bump minor` on `1.2.3` => `1.4.0` ("bump minor version twice") The `--bump` flags are sorted by their priority, so that you don't need to remember the priority yourself. This ordering is the only "useful" one that preserves every `--bump` you passed, so there's no concern about loss of expressiveness. For instance `--bump minor --bump major` would just be `--bump major` if we didn't sort, as the major bump clears the minor version. The ordering of `beta` after `alpha` means `--bump alpha --bump beta` will just result in beta 1; this is the one case where a bump request will effectively get overwritten. The `stable` mode "bumps to the next stable release", clearing the pre (`alpha`, `beta`, `rc`), `dev`, and `post` components from a version (`1.2.3a4.post5.dev6` => `1.2.3`). The choice to clear `post` here is a bit odd, in that `1.2.3.post4` => `1.2.3` is actually a version decrease, but I think this gives a more intuitive model (as preserving `post5` in the previous example is definitely wrong), and also post-releases are extremely obscure so probably no one will notice. In the cases where this behaviour isn't useful, you probably wanted to pass `--bump patch` or something anyway which *should* definitely clear the `post5` (putting it another way: the only cases where `--bump stable` has dubious behaviour is when you wanted it to do a noop, which, is a command you could have just not written at all). In all cases we preserve the "epoch" and "local" components of a version, so the `7!` and `+local` in `7!1.2.3+local` will never be modified by `--bump` (you can use the raw version set mode if you want to touch those). The preservation of `local` is another slightly odd choice, but it's a really obscure feature (so again it mostly won't come up) and when it's used it seems to mostly be used for referring to variant releases, in which case preserving it tends to be correct. Fixes #13223 --------- Co-authored-by: Zanie Blue <contact@zanie.dev>
275 lines
7.2 KiB
Markdown
275 lines
7.2 KiB
Markdown
---
|
|
title: Working on projects
|
|
description:
|
|
A guide to using uv to create and manage Python projects, including adding dependencies, running
|
|
commands, and building publishable distributions.
|
|
---
|
|
|
|
# Working on projects
|
|
|
|
uv supports managing Python projects, which define their dependencies in a `pyproject.toml` file.
|
|
|
|
## Creating a new project
|
|
|
|
You can create a new Python project using the `uv init` command:
|
|
|
|
```console
|
|
$ uv init hello-world
|
|
$ cd hello-world
|
|
```
|
|
|
|
Alternatively, you can initialize a project in the working directory:
|
|
|
|
```console
|
|
$ mkdir hello-world
|
|
$ cd hello-world
|
|
$ uv init
|
|
```
|
|
|
|
uv will create the following files:
|
|
|
|
```text
|
|
├── .gitignore
|
|
├── .python-version
|
|
├── README.md
|
|
├── main.py
|
|
└── pyproject.toml
|
|
```
|
|
|
|
The `main.py` file contains a simple "Hello world" program. Try it out with `uv run`:
|
|
|
|
```console
|
|
$ uv run main.py
|
|
Hello from hello-world!
|
|
```
|
|
|
|
## Project structure
|
|
|
|
A project consists of a few important parts that work together and allow uv to manage your project.
|
|
In addition to the files created by `uv init`, uv will create a virtual environment and `uv.lock`
|
|
file in the root of your project the first time you run a project command, i.e., `uv run`,
|
|
`uv sync`, or `uv lock`.
|
|
|
|
A complete listing would look like:
|
|
|
|
```text
|
|
.
|
|
├── .venv
|
|
│ ├── bin
|
|
│ ├── lib
|
|
│ └── pyvenv.cfg
|
|
├── .python-version
|
|
├── README.md
|
|
├── main.py
|
|
├── pyproject.toml
|
|
└── uv.lock
|
|
```
|
|
|
|
### `pyproject.toml`
|
|
|
|
The `pyproject.toml` contains metadata about your project:
|
|
|
|
```toml title="pyproject.toml"
|
|
[project]
|
|
name = "hello-world"
|
|
version = "0.1.0"
|
|
description = "Add your description here"
|
|
readme = "README.md"
|
|
dependencies = []
|
|
```
|
|
|
|
You'll use this file to specify dependencies, as well as details about the project such as its
|
|
description or license. You can edit this file manually, or use commands like `uv add` and
|
|
`uv remove` to manage your project from the terminal.
|
|
|
|
!!! tip
|
|
|
|
See the official [`pyproject.toml` guide](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/)
|
|
for more details on getting started with the `pyproject.toml` format.
|
|
|
|
You'll also use this file to specify uv [configuration options](../concepts/configuration-files.md)
|
|
in a [`[tool.uv]`](../reference/settings.md) section.
|
|
|
|
### `.python-version`
|
|
|
|
The `.python-version` file contains the project's default Python version. This file tells uv which
|
|
Python version to use when creating the project's virtual environment.
|
|
|
|
### `.venv`
|
|
|
|
The `.venv` folder contains your project's virtual environment, a Python environment that is
|
|
isolated from the rest of your system. This is where uv will install your project's dependencies.
|
|
|
|
See the [project environment](../concepts/projects/layout.md#the-project-environment) documentation
|
|
for more details.
|
|
|
|
### `uv.lock`
|
|
|
|
`uv.lock` is a cross-platform lockfile that contains exact information about your project's
|
|
dependencies. Unlike the `pyproject.toml` which is used to specify the broad requirements of your
|
|
project, the lockfile contains the exact resolved versions that are installed in the project
|
|
environment. This file should be checked into version control, allowing for consistent and
|
|
reproducible installations across machines.
|
|
|
|
`uv.lock` is a human-readable TOML file but is managed by uv and should not be edited manually.
|
|
|
|
See the [lockfile](../concepts/projects/layout.md#the-lockfile) documentation for more details.
|
|
|
|
## Managing dependencies
|
|
|
|
You can add dependencies to your `pyproject.toml` with the `uv add` command. This will also update
|
|
the lockfile and project environment:
|
|
|
|
```console
|
|
$ uv add requests
|
|
```
|
|
|
|
You can also specify version constraints or alternative sources:
|
|
|
|
```console
|
|
$ # Specify a version constraint
|
|
$ uv add 'requests==2.31.0'
|
|
|
|
$ # Add a git dependency
|
|
$ uv add git+https://github.com/psf/requests
|
|
```
|
|
|
|
If you're migrating from a `requirements.txt` file, you can use `uv add` with the `-r` flag to add
|
|
all dependencies from the file:
|
|
|
|
```console
|
|
$ # Add all dependencies from `requirements.txt`.
|
|
$ uv add -r requirements.txt -c constraints.txt
|
|
```
|
|
|
|
To remove a package, you can use `uv remove`:
|
|
|
|
```console
|
|
$ uv remove requests
|
|
```
|
|
|
|
To upgrade a package, run `uv lock` with the `--upgrade-package` flag:
|
|
|
|
```console
|
|
$ uv lock --upgrade-package requests
|
|
```
|
|
|
|
The `--upgrade-package` flag will attempt to update the specified package to the latest compatible
|
|
version, while keeping the rest of the lockfile intact.
|
|
|
|
See the documentation on [managing dependencies](../concepts/projects/dependencies.md) for more
|
|
details.
|
|
|
|
## Managing version
|
|
|
|
The `uv version` command can be used to read your package's version.
|
|
|
|
To get the version of your package, run `uv version`:
|
|
|
|
```console
|
|
$ uv version
|
|
hello-world 0.7.0
|
|
```
|
|
|
|
To get the version without the package name, use the `--short` option:
|
|
|
|
```console
|
|
$ uv version --short
|
|
0.7.0
|
|
```
|
|
|
|
To get version information in a JSON format, use the `--output-format json` option:
|
|
|
|
```console
|
|
$ uv version --output-format json
|
|
{
|
|
"package_name": "hello-world",
|
|
"version": "0.7.0",
|
|
"commit_info": null
|
|
}
|
|
```
|
|
|
|
See the [publishing guide](./package.md#updating-your-version) for details on updating your package
|
|
version.
|
|
|
|
## Running commands
|
|
|
|
`uv run` can be used to run arbitrary scripts or commands in your project environment.
|
|
|
|
Prior to every `uv run` invocation, uv will verify that the lockfile is up-to-date with the
|
|
`pyproject.toml`, and that the environment is up-to-date with the lockfile, keeping your project
|
|
in-sync without the need for manual intervention. `uv run` guarantees that your command is run in a
|
|
consistent, locked environment.
|
|
|
|
For example, to use `flask`:
|
|
|
|
```console
|
|
$ uv add flask
|
|
$ uv run -- flask run -p 3000
|
|
```
|
|
|
|
Or, to run a script:
|
|
|
|
```python title="example.py"
|
|
# Require a project dependency
|
|
import flask
|
|
|
|
print("hello world")
|
|
```
|
|
|
|
```console
|
|
$ uv run example.py
|
|
```
|
|
|
|
Alternatively, you can use `uv sync` to manually update the environment then activate it before
|
|
executing a command:
|
|
|
|
=== "macOS and Linux"
|
|
|
|
```console
|
|
$ uv sync
|
|
$ source .venv/bin/activate
|
|
$ flask run -p 3000
|
|
$ python example.py
|
|
```
|
|
|
|
=== "Windows"
|
|
|
|
```pwsh-session
|
|
PS> uv sync
|
|
PS> .venv\Scripts\activate
|
|
PS> flask run -p 3000
|
|
PS> python example.py
|
|
```
|
|
|
|
!!! note
|
|
|
|
The virtual environment must be active to run scripts and commands in the project without `uv run`. Virtual environment activation differs per shell and platform.
|
|
|
|
See the documentation on [running commands and scripts](../concepts/projects/run.md) in projects for
|
|
more details.
|
|
|
|
## Building distributions
|
|
|
|
`uv build` can be used to build source distributions and binary distributions (wheel) for your
|
|
project.
|
|
|
|
By default, `uv build` will build the project in the current directory, and place the built
|
|
artifacts in a `dist/` subdirectory:
|
|
|
|
```console
|
|
$ uv build
|
|
$ ls dist/
|
|
hello-world-0.1.0-py3-none-any.whl
|
|
hello-world-0.1.0.tar.gz
|
|
```
|
|
|
|
See the documentation on [building projects](../concepts/projects/build.md) for more details.
|
|
|
|
## Next steps
|
|
|
|
To learn more about working on projects with uv, see the
|
|
[projects concept](../concepts/projects/index.md) page and the
|
|
[command reference](../reference/cli.md#uv).
|
|
|
|
Or, read on to learn how to [build and publish your project to a package index](./package.md).
|