967 commits

Author	SHA1	Message	Date
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
konsti	95c1463965	Update dependabot support status (#13690) ... Following user reports and https://github.com/dependabot/dependabot-core/issues?q=state%3Aopen%20label%3A%22L%3A%20python%3Auv%22%20sort%3Areactions-%2B1-desc, we're updating the dependabot support as partial. See https://github.com/astral-sh/uv/issues/2512#issuecomment-2900063741	2025-05-27 16:55:12 -05:00
Eva Müller	df00189ec5	docs: Explicitly specify to add a new repo entry to the repos list item in the .pre-commit-config.yaml (#10243) ... <!-- 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 When creating the `.pre-commit-config.yaml` from scratch, although following https://pre-commit.com/, it might be easy to overlook that the pre-commit repo examples need to be added below the `repos` list item to get a valid `yaml` file. Additionally, updated the version of the first two examples. ## Test Plan I followed the `CONTRIBUTING.md` and the result looked fine. --------- Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-05-27 16:25:23 +00:00
Jay Qi	2db1630f54	Add documentation about Python versions to Tools concept page (#7673) ... <!-- 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 Add documentation about Python versions to Tools concept page ## Test Plan N/A --------- Co-authored-by: Jay Qi <jayqi@users.noreply.github.com> Co-authored-by: Zanie Blue <contact@zanie.dev>	2025-05-27 16:23:29 +00:00
Arne Küderle	f657359729	Quote versions variables in GitLab documentation ... ## Summary Fixes #13675 ## Test Plan New example was tested manually to verify that it works.	2025-05-27 08:43:30 -04:00
Aria Desires	0ddcc19055	Bump version to 0.7.8 (#13629)	2025-05-23 19:13:28 -04:00
John Mumm	3758c513a4	Remove misleading line in pin documentation (#13611) ... The documentation did not reflect #12921.	2025-05-23 09:04:50 +02:00
Aria Desires	8580b4bd2d	Bump version to 0.7.7 (#13601)	2025-05-22 14:42:26 -04:00
konsti	46bc7d3477	Build backend: Support stubs packages (#13563) ... Stubs packages are different in that their name ends with `-stubs`, their module is `<module name>-stubs` (with a dash, not the generally legal underscore) and their modules contain a `__init__.pyi` instead of an `__init__.py` (https://typing.python.org/en/latest/spec/distributing.html#stub-only-packages). We add support in the uv build backend by detecting the `-stubs` suffix. Fixes #13546 --------- Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>	2025-05-22 19:02:17 +02:00
renovate[bot]	c7cabfccd7	Update markdown to v1 and fix CLI reference links (#13166) ... This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [markdown](https://redirect.github.com/wooorm/markdown-rs) | dependencies | major | `0.3.0` -> `1.0.0` | --- ### Release Notes <details> <summary>wooorm/markdown-rs (markdown)</summary> ### [`v1.0.0`](https://redirect.github.com/wooorm/markdown-rs/releases/tag/1.0.0) 💯 Nothing changed since the last alpha. It’s just that: this crate’s now being used a bunch and working well, so it’s time to be stable! </details> --- ### Configuration 📅 **Schedule**: Branch creation - "before 4am on Monday" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/astral-sh/uv). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNTcuMyIsInVwZGF0ZWRJblZlciI6IjM5LjI1Ny4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJpbnRlcm5hbCJdfQ==--> --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: konstin <konstin@mailbox.org>	2025-05-21 22:50:09 +02:00
Aria Desires	38884da9b9	make uv version lock and sync (#13317) ... This adopts the logic from `uv remove` for locking and syncing, as the scope of the changes made are ultimately similar. Unlike `uv remove` there is no support for modifying PEP723 scripts, as these are not versioned. In doing this the `version` command gains a truckload of args for configuring lock/sync behaviour. Presumably most of these are passed via settings or env files, and not of particular concern. The most interesting additions are: * `--frozen`: makes `uv version` work ~exactly as it did before this PR * `--locked`: errors if the lockfile is out of date * `--no-sync`: updates the lockfile, but doesn't run the equivalent of `uv sync` * `--package name`: a convenience for referring to a package in the workspace Note that the existing `--dry-run` flag effectively implies `--frozen` for sets and bumps. Fixes #13254 Fixes #13548	2025-05-21 09:46:09 -04:00
Art O Cathain	1bee9320f1	Clarify adding SSH Git dependencies (#13534) ... The current instructions say > prefix a Git-compatible URL (i.e., that you would use with git clone) with git+. But this does not work with the URL that Github gives you when you choose Clone -> SSH via the UI, which is of the form `git@github.com:astral-sh/uv.git`. If you prefix this with `git+`, i.e. `git+git@github.com:astral-sh/uv.git` it does not work. --------- Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>	2025-05-20 14:20:15 +00:00
Zanie Blue	7f3e94a091	Bump version to 0.7.6 (#13537) ... Co-authored-by: Aria Desires <aria.desires@gmail.com>	2025-05-19 19:46:11 -04:00
Reza Gharibi	d4e8df9b94	Fix PowerShell code blocks (#13511) ... <!-- 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 The PowerShell prompt is not `$`, so it is not detected as a `Generic.Prompt` token by Pygments lexers. Therefore, the JavaScript code does not strip the prompt when copying from PowerShell code blocks, such as [here](https://docs.astral.sh/uv/getting-started/installation/#__tabbed_5_2). Other places in the docs have removed the prompt completely to address this issue: * https://docs.astral.sh/uv/guides/projects/#__tabbed_1_2 * https://docs.astral.sh/uv/guides/integration/jupyter/#__tabbed_1_2 This PR updates the PowerShell prompt to `PS>` and changes the code fence language to `pwsh-session` to match the lexer name from [Pygments](https://pygments.org/docs/lexers/#pygments.lexers.shell.PowerShellSessionLexer). This allows the prompt to be correctly detected as a `Generic.Prompt` token and is stripped during copy. Related: https://github.com/astral-sh/uv/pull/12520	2025-05-17 21:06:48 -05:00
Charlie Marsh	9d1a14e1f9	Bump version to v0.7.5 (#13500)	2025-05-16 20:37:17 -04:00
konsti	77268ee152	Build backend: Case sensitive module discovery (#13468) ... We may run on case-sensitive file systems (Linux, generally) or on case-insensitive file systems (Windows, generally), while modules in Python may be lower or upper case. For robustness over filesystem casing, we require an explicit module name for modules with upper cases. Fixes #13419	2025-05-16 14:25:35 +02:00