982 commits

Author	SHA1	Message	Date
Charlie Marsh	e104eea34a	Bump --python-platform linux to manylinux_2_28 (#14300) ... Right now, `--python-platform linux` to defaults to `manylinux_2_17`. Defaulting to `manylinux_2_17` causes some problems for users, since it means we can't use (e.g.) `manylinux_2_28` wheels, and end up having to build from source. cibuildwheel made `manylinux_2_28` their default in https://github.com/pypa/cibuildwheel/pull/1988, and there's a lot of discussion in https://github.com/pypa/cibuildwheel/issues/1772 and https://github.com/pypa/cibuildwheel/issues/2047. In short, the `manylinux_2014` image is EOL, and the vast majority of consumers now run at least glibc 2.28 (https://mayeut.github.io/manylinux-timeline/):  Note that this only changes the _default_. Users can still compile against `manylinux_2_17` by specifying it.	2025-07-01 20:02:34 -05:00
samypr100	e40357e529	feat(docker): set default UV_TOOL_BIN_DIR on docker images (#13391) ... Closes #13057 Sets `UV_TOOL_BIN_DIR` to `/usr/local/bin` for all derived images to allow `uv tool install` to work out of the box. Note, when the default image user is overwritten (e.g. `USER <UID>`) by a less privileged one, an alternative writable location would now need to be set by downstream consumers to prevent issues, hence I'm labeling this as a breaking change for 0.8.x release. Relates to https://github.com/astral-sh/uv-docker-example/pull/55 Each image was tested to work with uv tool with `UV_TOOL_BIN_DIR` set to `/usr/local/bin` with the default root user and alternative non-root users to confirm breaking nature of the change.	2025-07-01 20:02:34 -05:00
Zanie Blue	87e9ccfb92	Bump version to 0.7.18 (#14402)	2025-07-01 15:30:44 -05:00
Zanie Blue	b1812d111a	Edits to the build backend documentation (#14376) ... Co-authored-by: konstin <konstin@mailbox.org>	2025-07-01 08:44:23 +00:00
Ondrej Profant	ae500c95d2	Docs: add instructions for publishing to JFrog's Artifactory (#14253) ... ## Summary Add instructions for publishing to JFrog's Artifactory into [documentation](https://docs.astral.sh/uv/guides/integration/alternative-indexes/). Related issues: https://github.com/astral-sh/uv/issues/9845 https://github.com/astral-sh/uv/issues/10193 ## Test Plan I ran the documentation locally and use npx prettier. --------- Co-authored-by: Ondrej Profant <ondrej.profant@datamole.ai> Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-06-30 13:58:55 +00:00
Charlie Marsh	41c218a89b	Bump version to 0.7.17 (#14347)	2025-06-29 09:58:33 -04:00
Zanie Blue	ec18f4813a	Fix typo (#14341)	2025-06-28 11:32:03 -05:00
Zanie Blue	b6b7409d13	Bump version to 0.7.16 (#14334)	2025-06-27 16:46:36 -05:00
Daniel Vianna	4b348512c2	GCP Artifact Registry download URLs must have /simple path (#14251)	2025-06-25 17:35:41 +02:00
John Mumm	4ed9c5791b	Bump version to 0.7.15 (#14254)	2025-06-25 12:06:41 +02:00
John Mumm	5b2c3595a7	Require disambiguated relative paths for --index (#14152) ... We do not currently support passing index names to `--index` for installing packages. However, we do accept relative paths that can look like index names. This PR adds the requirement that `--index` values must be disambiguated with a prefix (`./` or `../` on Unix and Windows or `.\\` or `..\\` on Windows). For now, if an ambiguous value is provided, uv will warn that this will not be supported in the future. Currently, if you provide an index name like `--index test` when there is no `test` directory, uv will error with a `Directory not found...` error. That's not very informative if you thought index names were supported. The new warning makes the context clearer. Closes #13921	2025-06-25 10:02:06 +02:00
dmitry-bychkov	61265b0c14	Add a link to PyPI FAQ to clarify what per-project token is. (#14242) ... <!-- 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 This change adds a link to PyPI FAQ about API tokens on the package publishing guide page. To me it wasn't clear what are meant in this section of the docs and it required a little bit of research. Adding explicit link might help beginners. <!-- What's the purpose of the change? What does it do, and why? --> Co-authored-by: Dmitry Bychkov <dbychkov@alarislabs.com>	2025-06-24 11:56:36 -04:00
Aria Desires	92de53f4eb	Bump version to 0.7.14 (#14218)	2025-06-23 12:48:51 -04:00
Charlie Marsh	a82c210cab	Add auto-detection for AMD GPUs (#14176) ... ## Summary Allows `--torch-backend=auto` to detect AMD GPUs. The approach is fairly well-documented inline, but I opted for `rocm_agent_enumerator` over (e.g.) `rocminfo` since it seems to be the recommended approach for scripting: https://rocm.docs.amd.com/projects/rocminfo/en/latest/how-to/use-rocm-agent-enumerator.html. Closes https://github.com/astral-sh/uv/issues/14086. ## Test Plan ``` root@rocm-jupyter-gpu-mi300x1-192gb-devcloud-atl1:~# ./uv-linux-libc-11fb582c5c046bae09766ceddd276dcc5bb41218/uv pip install torch --torch-backend=auto Resolved 11 packages in 251ms Prepared 2 packages in 6ms Installed 11 packages in 257ms + filelock==3.18.0 + fsspec==2025.5.1 + jinja2==3.1.6 + markupsafe==3.0.2 + mpmath==1.3.0 + networkx==3.5 + pytorch-triton-rocm==3.3.1 + setuptools==80.9.0 + sympy==1.14.0 + torch==2.7.1+rocm6.3 + typing-extensions==4.14.0 ``` --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-06-21 15:21:06 +00:00
Charlie Marsh	e59835d50c	Add XPU to --torch-backend (#14172) ... ## Summary Like ROCm, no auto-detection for now.	2025-06-20 20:33:20 -04:00
Lucas Vittor	563e9495ba	Replace cuda124 with cuda128 (#14168) ... ## Summary <!-- What's the purpose of the change? What does it do, and why? --> Replace wrong `cuda124` version to the correct `cuda128` version in torch docs ## Test Plan <!-- How was it tested? -->	2025-06-20 16:05:17 -04:00
John Mumm	e9d5780369	Support transparent Python patch version upgrades (#13954) ... > NOTE: The PRs that were merged into this feature branch have all been independently reviewed. But it's also useful to see all of the changes in their final form. I've added comments to significant changes throughout the PR to aid discussion. This PR introduces transparent Python version upgrades to uv, allowing for a smoother experience when upgrading to new patch versions. Previously, upgrading Python patch versions required manual updates to each virtual environment. Now, virtual environments can transparently upgrade to newer patch versions. Due to significant changes in how uv installs and executes managed Python executables, this functionality is initially available behind a `--preview` flag. Once an installation has been made upgradeable through `--preview`, subsequent operations (like `uv venv -p 3.10` or patch upgrades) will work without requiring the flag again. This is accomplished by checking for the existence of a minor version symlink directory (or junction on Windows). ### Features * New `uv python upgrade` command to upgrade installed Python versions to the latest available patch release: ``` # Upgrade specific minor version uv python upgrade 3.12 --preview # Upgrade all installed minor versions uv python upgrade --preview ``` * Transparent upgrades also occur when installing newer patch versions: ``` uv python install 3.10.8 --preview # Automatically upgrades existing 3.10 environments uv python install 3.10.18 ``` * Support for transparently upgradeable Python `bin` installations via `--preview` flag ``` uv python install 3.13 --preview # Automatically upgrades the `bin` installation if there is a newer patch version available uv python upgrade 3.13 --preview ``` * Virtual environments can still be tied to a patch version if desired (ignoring patch upgrades): ``` uv venv -p 3.10.8 ``` ### Implementation Transparent upgrades are implemented using: * Minor version symlink directories (Unix) or junctions (Windows) * On Windows, trampolines simulate paths with junctions * Symlink directory naming follows Python build standalone format: e.g., `cpython-3.10-macos-aarch64-none` * Upgrades are scoped to the minor version key (as represented in the naming format: implementation-minor version+variant-os-arch-libc) * If the context does not provide a patch version request and the interpreter is from a managed CPython installation, the `Interpreter` used by `uv python run` will use the full symlink directory executable path when available, enabling transparently upgradeable environments created with the `venv` module (`uv run python -m venv`) New types: * `PythonMinorVersionLink`: in a sense, the core type for this PR, this is a representation of a minor version symlink directory (or junction on Windows) that points to the highest installed managed CPython patch version for a minor version key. * `PythonInstallationMinorVersionKey`: provides a view into a `PythonInstallationKey` that excludes the patch and prerelease. This is used for grouping installations by minor version key (e.g., to find the highest available patch installation for that minor version key) and for minor version directory naming. ### Compatibility * Supports virtual environments created with: * `uv venv` * `uv run python -m venv` (using managed Python that was installed or upgraded with `--preview`) * Virtual environments created within these environments * Existing virtual environments from before these changes continue to work but aren't transparently upgradeable without being recreated * Supports both standard Python (`python3.10`) and freethreaded Python (`python3.10t`) * Support for transparently upgrades is currently only available for managed CPython installations Closes #7287 Closes #7325 Closes #7892 Closes #9031 Closes #12977 --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-06-20 16:17:13 +02:00
Jack O'Connor	cc8d5a9215	handle an existing shebang in uv init --script (#14141) ... Closes https://github.com/astral-sh/uv/issues/14085.	2025-06-19 14:47:22 -07:00
Jack O'Connor	c3e4b63806	document the way member sources shadow workspace sources ... Closes https://github.com/astral-sh/uv/issues/14093.	2025-06-18 15:31:23 -07:00
Charlie Marsh	4d9c9a1e76	Add ROCm backends to --torch-backend (#14120) ... We don't yet support automatic detection, but this at least allows explicit selection (e.g., `uv pip install --torch-backend rocm5.3`). Closes #14087.	2025-06-18 07:35:05 -04:00
Charlie Marsh	6c096246d8	Remove preview label from --torch-backend (#14119) ... This is now used in enough places that I'm comfortable committing to maintaining it under our versioning policy. Closes #14091.	2025-06-17 16:49:00 -04:00
FishAlchemist	d653fbb133	doc: Sync PyTorch integration index for CUDA and ROCm versions from PyTorch website. (#14100) ... ## Summary Just to sync the documentation with PyTorch's officially recommended installation method.  **Change:** * CUDA 12.1 to CUDA 12.6 * CUDA 12.4 to CUDA 12.8 * ROCm 6.2 to ROCm 6.3 ## Test Plan Run doc server in local. Result: <details><summary>CUDA 12.6</summary> <p>   </p> </details> <details><summary>CUDA 12.8</summary> <p>   </p> </details> <details><summary>ROCm6</summary> <p>   </p> </details>	2025-06-17 09:55:03 -04:00
Aria Desires	5021840919	Add [tool.uv.dependency-groups].mygroup.requires-python (#13735) ... This allows you to specify requires-python on individual dependency-groups, with the intended usecase being "oh my dev-dependencies have a higher requires-python than my actual project". This includes a large driveby move of the RequiresPython type to uv-distribution-types to allow us to generate the appropriate markers at this point in the code. It also migrates RequiresPython from pubgrub::Range to version_ranges::Ranges, and makes several pub(crate) items pub, as it's no longer defined in uv_resolver. Fixes #11606	2025-06-13 22:04:13 +00:00
Zanie Blue	62ed17b230	Bump version to 0.7.13 (#14002)	2025-06-12 14:33:31 -05:00
konsti	7316bd01a3	Build backend: Support namespace packages (#13833) ... Unlike regular packages, specifying all `__init__.py` directories for a namespace package would be very verbose There is e.g. https://github.com/python-poetry/poetry/tree/main/src/poetry, which has 18 modules, or https://github.com/googleapis/api-common-protos which is inconsistently nested. For both the Google Cloud SDK, there are both packages with a single module and those with complex structures, with many having multiple modules due to versioning through `<module>_v1` versioning. The Azure SDK seems to use one module per package (it's not explicitly documented but seems to follow from the process in https://azure.github.io/azure-sdk/python_design.html#azure-sdk-distribution-packages and ccb0e03a3d/doc/dev/packaging.md). For simplicity with complex projects, we add a `namespace = true` switch which disabled checking for an `__init__.py`. We only check that there's no `<module_root>/<module_name>/__init__.py` and otherwise add the whole `<module_root>/<module_name>` folder. This comes at the cost of `namespace = true` effectively creating an opt-out from our usual checks that allows creating an almost entirely arbitrary package. For simple projects with only a single module, the module name can be dotted to point to the target module, so the build still gets checked: ```toml [tool.uv.build-backend] module-name = "poetry.core" ``` ## Alternatives ### Declare all packages We could make `module-name` a list and allow or require declaring all packages: ```toml [tool.uv.build-backend] module-name = ["cloud_sdk.service.storage", "cloud_sdk.service.storage_v1", "cloud_sdk.billing.storage"] ``` Or for Poetry: ```toml [tool.uv.build-backend] module-name = [ "poetry.config", "poetry.console", "poetry.inspection", "poetry.installation", "poetry.json", "poetry.layouts", "poetry.masonry", "poetry.mixology", "poetry.packages", "poetry.plugins", "poetry.publishing", "poetry.puzzle", "poetry.pyproject", "poetry.repositories", "poetry.toml", "poetry.utils", "poetry.vcs", "poetry.version" ] ``` ### Support multiple namespaces We could also allow namespace packages with multiple root level module: ```toml [tool.uv.build-backend] module-name = ["cloud_sdk.my_ext", "local_sdk.my_ext"] ``` For lack of use cases, we delegate this to creating a workspace with one package per module. ## Implementation Due to the more complex options for the module name, I'm moving verification on deserialization later, dropping the source span we'd get from serde. We also don't show similarly named directories anymore. --------- Co-authored-by: Andrew Gallant <andrew@astral.sh>	2025-06-12 17:23:58 +00:00
Zanie Blue	95ad8e5e82	Add 3.14 to the supported platform reference (#13990)	2025-06-12 15:18:48 +00:00
Zanie Blue	e067118700	Add supported macOS version to the platform reference (#13993) ... Closes https://github.com/astral-sh/uv/issues/13807	2025-06-12 15:16:24 +00:00
Zanie Blue	f82909ad68	Update platform support reference to include Python implementation list (#13991)	2025-06-12 10:14:42 -05:00
Zanie Blue	87ab57e902	Update the CLI help and reference to include references to the Python bin directory (#13978) ... Closes https://github.com/astral-sh/uv/issues/13977	2025-06-12 10:02:51 +00:00
Zanie Blue	4c877b7dc6	Fix generated file change (#13957) ... Regressed in https://github.com/astral-sh/uv/pull/13620 ref failure at 4384658790	2025-06-10 22:03:01 +00:00
Lan, Jian	90a7208a73	Fix and improve docs (#13620) ... <!-- 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 I follow the advices from the IDE spell checker and grammar checker, fix some typos, and improve the docs.	2025-06-10 13:15:38 -05:00
Charlie Marsh	28685633c0	Add an llms.txt to uv (#13929) ... ## Summary The generated file looks like: ``` # uv > uv is an extremely fast Python package and project manager, written in Rust. You can use uv to install Python dependencies, run scripts, manage virtual environments, build and publish packages, and even install Python itself. uv is capable of replacing `pip`, `pip-tools`, `pipx`, `poetry`, `pyenv`, `twine`, `virtualenv`, and more. uv includes both a pip-compatible CLI (prepend `uv` to a pip command, e.g., `uv pip install ruff`) and a first-class project interface (e.g., `uv add ruff`) complete with lockfiles and workspace support. ## Getting started - [Features](https://docs.astral.sh/uv/getting-started/features/index.md) - [First steps](https://docs.astral.sh/uv/getting-started/first-steps/index.md) - [Installation](https://docs.astral.sh/uv/getting-started/installation/index.md) ## Guides - [Installing Python](https://docs.astral.sh/uv/guides/install-python/index.md) - [Publishing packages](https://docs.astral.sh/uv/guides/package/index.md) - [Working on projects](https://docs.astral.sh/uv/guides/projects/index.md) - [Running scripts](https://docs.astral.sh/uv/guides/scripts/index.md) - [Using tools](https://docs.astral.sh/uv/guides/tools/index.md) ## Integrations - [Alternative indexes](https://docs.astral.sh/uv/guides/integration/alternative-indexes/index.md) - [AWS Lambda](https://docs.astral.sh/uv/guides/integration/aws-lambda/index.md) - [Dependency bots](https://docs.astral.sh/uv/guides/integration/dependency-bots/index.md) - [Docker](https://docs.astral.sh/uv/guides/integration/docker/index.md) - [FastAPI](https://docs.astral.sh/uv/guides/integration/fastapi/index.md) - [GitHub Actions](https://docs.astral.sh/uv/guides/integration/github/index.md) - [GitLab CI/CD](https://docs.astral.sh/uv/guides/integration/gitlab/index.md) - [Jupyter](https://docs.astral.sh/uv/guides/integration/jupyter/index.md) - [marimo](https://docs.astral.sh/uv/guides/integration/marimo/index.md) - [Pre-commit](https://docs.astral.sh/uv/guides/integration/pre-commit/index.md) - [PyTorch](https://docs.astral.sh/uv/guides/integration/pytorch/index.md) ## Projects - [Building distributions](https://docs.astral.sh/uv/concepts/projects/build/index.md) - [Configuring projects](https://docs.astral.sh/uv/concepts/projects/config/index.md) - [Managing dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/index.md) - [Creating projects](https://docs.astral.sh/uv/concepts/projects/init/index.md) - [Structure and files](https://docs.astral.sh/uv/concepts/projects/layout/index.md) - [Running commands](https://docs.astral.sh/uv/concepts/projects/run/index.md) - [Locking and syncing](https://docs.astral.sh/uv/concepts/projects/sync/index.md) - [Using workspaces](https://docs.astral.sh/uv/concepts/projects/workspaces/index.md) ## Features - [Authentication](https://docs.astral.sh/uv/concepts/authentication/index.md) - [Build backend](https://docs.astral.sh/uv/concepts/build-backend/index.md) - [Caching](https://docs.astral.sh/uv/concepts/cache/index.md) - [Configuration files](https://docs.astral.sh/uv/concepts/configuration-files/index.md) - [Package indexes](https://docs.astral.sh/uv/concepts/indexes/index.md) - [Python versions](https://docs.astral.sh/uv/concepts/python-versions/index.md) - [Resolution](https://docs.astral.sh/uv/concepts/resolution/index.md) - [Tools](https://docs.astral.sh/uv/concepts/tools/index.md) ## The pip interface - [Compatibility with pip](https://docs.astral.sh/uv/pip/compatibility/index.md) - [Locking environments](https://docs.astral.sh/uv/pip/compile/index.md) - [Declaring dependencies](https://docs.astral.sh/uv/pip/dependencies/index.md) - [Using environments](https://docs.astral.sh/uv/pip/environments/index.md) - [Inspecting environments](https://docs.astral.sh/uv/pip/inspection/index.md) - [Managing packages](https://docs.astral.sh/uv/pip/packages/index.md) ## Reference - [Commands](https://docs.astral.sh/uv/reference/cli/index.md) - [Environment variables](https://docs.astral.sh/uv/reference/environment/index.md) - [Installer](https://docs.astral.sh/uv/reference/installer/index.md) - [Settings](https://docs.astral.sh/uv/reference/settings/index.md) ``` Closes #13901.	2025-06-10 07:46:49 -04:00
Jack O'Connor	dc455bfc26	add UV_NO_GITHUB_FAST_PATH	2025-06-09 23:50:36 +00:00
Karim Abou Zeid	5dae9ac5f2	Update referenced CUDA version in pytorch.md (#13899) ... ## Summary torch 2.7 by default targets CUDA 12.6	2025-06-08 20:21:07 -04:00
Zanie Blue	dc3fd46472	Bump version to 0.7.12 (#13892)	2025-06-06 19:42:06 +00:00
Jack O'Connor	94ed6f880f	update Git and GitHub Actions docs to mention gh auth login (#13850)	2025-06-05 20:44:59 +00:00
Zanie Blue	262ca73965	Remove the configuration section in favor of concepts / reference (#13842) ... Extends https://github.com/astral-sh/uv/pull/13841 — I'll drop that commit later after that pull request merges but it's small. I find the split into a "Configuration" section awkward and don't think it's helping us. Everything moved into the "Concepts" section, except the "Environment variables" page which definitely belongs in the reference and the "Installer" page which is fairly niche and seems better in the reference. Before / After <img src="https://github.com/user-attachments/assets/80d8304b-17da-4900-a5f4-c3ccac96fcc5" width="400">	2025-06-05 17:09:49 +00:00
Zanie Blue	062b6ab743	Add uv python pin --rm to remove .python-version pins (#13860) ... I realized it is non-trivial to delete the global Python version pin, and that we were missing this simple functionality	2025-06-05 12:05:42 -05:00
Zanie Blue	789a246cf3	Move the pip interface documentation into the concepts section (#13841) ... The motivation here being a reduction in the length of the navigation. I don't think we did this in the first place because we didn't have the capability to do another nested level, but now we're doing that for Projects.	2025-06-05 11:53:27 -05:00
Abhishek Upadhye	efd4652faa	List .gitignore in project init files (#13855) ... Fixes https://github.com/astral-sh/uv/issues/13639 Just added a missing `.gitignore` file in the docs, so that there would be no confusion for readers referring it. Thank you!	2025-06-05 09:21:15 -05:00
Jack O'Connor	90a4416ab8	Bump version to 0.7.11 (#13844)	2025-06-04 12:35:56 -07:00
Zanie Blue	3ca8d074a4	Use "terminal driver" instead of "shell" in SIGINT docs (#13787) ... Addressing the comment at https://github.com/astral-sh/uv/issues/12108#issuecomment-2925703719	2025-06-03 22:07:03 +00:00
Hood Chatham	f9d3f24728	Add Pyodide support (#12731) ... This includes some initial work on adding Pyodide support (issue #12729). It is enough to get ``` uv pip compile -p /path/to/pyodide --extra-index-url file:/path/to/simple-index ``` to work which should already be quite useful. ## Test Plan * added a unit test for `pyodide_platform` * integration tested manually with: ``` cargo run pip install \ -p /home/rchatham/Documents/programming/tmp/pyodide-venv-test/.pyodide-xbuildenv-0.29.3/0.27.4/xbuildenv/pyodide-root/dist/python \ --extra-index-url file:/home/rchatham/Documents/programming/tmp/pyodide-venv-test/.pyodide-xbuildenv-0.29.3/0.27.4/xbuildenv/pyodide-root/package_index \ --index-strategy unsafe-best-match --target blah --no-build \ numpy pydantic ``` --------- Co-authored-by: konsti <konstin@mailbox.org> Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-06-03 12:01:26 -05:00
Zanie Blue	1e5120e15c	Bump version to 0.7.10 (#13821)	2025-06-03 11:07:21 -05:00
Tobias Gårdhus	459c902425	add --show-extras to uv tool list to list extra requirements installed with tools (#13783) ... ## Summary Implemented as suggested in #13761 eg. ``` $ uv tool install 'harlequin[postgres]' $ uv tool list --show-extras harlequin v2.1.2 [extras: postgres] - harlequin ``` ## Test Plan Added a new test with the argument along with the others from the `uv tool list` cli.	2025-06-02 14:59:40 +00:00
Zanie Blue	13a86a23b3	Bump version to 0.7.9 (#13739)	2025-05-30 14:30:37 -05:00
johnthagen	72e2821d26	Fix exclude-newer date format in docs (#13706) ... ## Summary Closes #13704	2025-05-28 20:23:10 +00:00
konsti	56203484a2	Add uv add --bounds to configure the version constraint (#12946) ... By default, uv uses only a lower bound in `uv add`, which avoids dependency conflicts due to upper bounds. With this PR, this cna be changed by setting a different bound kind. The bound kind can be configured in `uv.toml`, as a user preference, in `pyproject.toml`, as a project preference, or on the CLI, when adding a specific project. We add two options that add an upper bound on the constraint, one for SemVer (`>=1.2.3,<2.0.0`, dubbed "major", modeled after the SemVer caret) and another one for dependencies that make breaking changes in minor version (`>=1.2.3,<1.3.0`, dubbed "minor", modeled after the SemVer tilde). Intuitively, the major option bumps the most significant version component, while the minor option bumps the second most significant version component. There is also an exact bounds option (`==1.2.3`), though generally we recommend setting a wider bound and using the lockfile for pinning. Versions can have leading zeroes, such as `0.1` or `0.0.1`. For a single leading 0, we shift the the meaning of major and minor similar to cargo. For two or more leading zeroes, the difference between major and minor becomes inapplicable, instead both bump the most significant component: - major: `0.1` -> `>=0.1,<0.2` - major: `0.0.1` -> `>=0.0.1,<0.0.2` - major: `0.0.1.1` -> `>=0.0.1.1,<0.0.2.0` - major: `0.0.0.1` -> `>=0.0.0.1,<0.0.0.2` - minor: `0.1` -> `>=0.1,<0.1.1` - minor: `0.0.1` -> `>=0.0.1,<0.0.2` - minor: `0.0.1.1` -> `>=0.0.1.1,<0.0.2.0` - minor: `0.0.0.1` -> `>=0.0.0.1,<0.0.0.2` For a consistent appearance, we try to preserve the number of components in the upper bound. For example, adding a version `2.17` with the major option is stored as `>=2.17,<3.0`. If a version uses three components and is greater than 0, both bounds will also use three components (SemVer versions always have three components). Of the top 100 PyPI packages, 8 use a non-three-component version (docutils, idna, pycparser and soupsieve with two components, packaging, pytz and tzdata with two component, CalVer and trove-classifiers with four component CalVer). Example `pyproject.toml` files with the top 100 packages: [`--bounds major`](https://gist.github.com/konstin/0aaffa9ea53c4834c22759e8865409f4) and [`--bounds minor`](https://gist.github.com/konstin/e77f5e990a7efe8a3c8a97c5c5b76964). While many projects follow version scheme that roughly or directly matches the major or minor options, these compatibility ranges are usually not applicable for the also popular CalVer versioning. For pre-release versions, there are two framings we could take: One is that pre-releases generally make no guarantees about compatibility between them and are used to introduce breaking changes, so we should pin them exactly. In many cases however, pre-release specifiers are used because a project needs a bugfix or a feature that hasn't made it into a stable release, or because a project is compatible with the next version before a final version for that release is published. In those cases, compatibility with other packages that depend on the same library is more important, so the desired bound is the same as it would be for the stable release, except with the lower bound lowered to include pre-release. The names of the bounds and the name of the flag is up for bikeshedding. Currently, the option is call `tool.uv.bounds`, but we could also move it under `tool.uv.edit.bounds`, where it would be the first/only entry. Fixes #6783 --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-05-28 13:11:31 +00:00
Zanie Blue	90a21ae46a	Add example of enabling Dependabot (#13692) ... Follows https://github.com/astral-sh/uv/pull/13690 Tested in https://github.com/astral-sh/packse/blob/main/.github/dependabot.yml	2025-05-28 11:10:14 +02:00
Akshay Agrawal	20cfc93c58	docs: integration with marimo guide (#13691) ... <!-- 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 This change adds a new integration guide, on using uv with marimo notebooks. It is similar to but simpler than the existing Jupyter guide, since marimo stores notebooks as Python files and also integrates tightly with uv for package management. The guide showcases four ways of using uv with marimo: 1. marimo as a standalone tool (`uvx`) 2. managing inline script metadata (an alternative to Jupyter kernels, marimo has no concept of kernels) 3. in project environments 4. in non-project environments ## Test Plan N/A as this is a docs-only change. --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-05-27 18:43:43 -05:00