uv/docs/guides/projects.md
Aria Desires 042df4a7de
Expand the functionality of uv version --bump to support pre-releases (#13578)
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>
2025-07-10 08:45:17 -05:00

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).