<!--
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.
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">
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>
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>
Add configuration documentation for the build backend and make it the
preview default.
The build backend should generally work with default configuration
unless you want specific features such as flat layout or module
renaming, there is only a dedicated configuration, but no concept or
guide page for the build backend. Once the build backend is stable, we
can update the guide documentation to explain that uv defaults to its
own build backend, but other build backends are also supported.
The uv build backend becomes the default in preview, giving it more
exposure from users and preparing it to make it the default proper. The
current documentation retains warnings that the build backend is in
preview.
To see current uses of `uv_build` on GitHub:
https://github.com/search?q=path%3A**%2Fpyproject.toml+uv_build%3E%3D0&type=code
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
The PyTorch guide page has this, but it's missing from this example
(which is otherwise identical to the PyTorch guide page). I think it
would be helpful to include it here too.
## Test Plan
Docs.
<!-- How was it tested? -->
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
## Summary
Adds note to docs about PEP 751 to documentation as discussed in #12641
## Test Plan
Previewed locally
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
Fix broken grammar and hl_lines.
<!--
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
Some simple doc fixes.
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
N/A
<!-- How was it tested? -->
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
<!--
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
Fixes#12334
<!-- What's the purpose of the change? What does it do, and why? -->
## Test Plan
<!-- How was it tested? -->
<!--
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
<!-- What's the purpose of the change? What does it do, and why? -->
The examples assume that the packages are in the project root directory.
However, they are nested inside `src`, and the commands in the examples
do not work as intended.
I could not find any related issues.
## Test Plan
<!-- How was it tested? -->
I tested it by executing the commands on my terminal - Linux and Windows
(PowerShell).
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
Follow up to https://github.com/astral-sh/uv/pull/11888 with added
support for uv tool run.
Changes
* Added functionality for running windows scripts in previous PR was
moved from run.rs to uv_shell::runnable.
* EXE was added as a supported type, this simplified integration across
both uv run and uvx while retaining a backwards compatible behavior and
properly prioritizing .exe over others. Name was adjusted to runnable as
a result to better represent intent.
## Test Plan
New tests added.
## Documentation
Added new documentation.
## Summary
In https://github.com/astral-sh/uv/issues/11998, a user is attempting to
vendor `pydantic-core`. But when they add `pydantic-core = { path =
"src/foo/vendor/pydantic-core" } `, we're installing it as a virtual
package, since `pydantic-core/pyproject.toml` contains `package =
false`.
This PR allows users to mark dependencies as "explicitly a package" or
"explicitly not a package" (i.e., virtual), as a workaround.
Closes https://github.com/astral-sh/uv/issues/11998.
I need to self-review this still.
Updates the "Locking and syncing" page to actually have content on
syncing — which was the original intent, the rest of this file was just
copied out of the "Projects" page when I split it into multiple pages.
---------
Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
<!--
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
<!-- What's the purpose of the change? What does it do, and why? -->
Fixes readme typo in syntax of environments in `pyproject.toml`
## Test Plan
<!-- How was it tested? -->
n/a
Initially it seemed like `app.py` might be slightly more desirable but
people seem to overwhelmingly favour `main.py` as a good "generic" name.
Fixes#7782
## Summary
I followed the docs to install flash-attn with uv and got the following
issue
```uv sync
Resolved 27 packages in 12ms
× Failed to build `flash-attn==2.7.4.post1`
├─▶ The build backend returned an error
╰─▶ Call to `setuptools.build_meta:__legacy__.build_wheel` failed (exit status: 1)
[stderr]
Traceback (most recent call last):
File "<string>", line 8, in <module>
ModuleNotFoundError: No module named 'setuptools'
hint: This usually indicates a problem with the package or the build environment.
```
installing setuptools before running uv sync as done with torch helps
fix it.
## Test Plan
I tested locally before it failed to install, after it worked
I think `UV_PROJECT_ENVIRONMENT` is too complicated for use-cases where
the user wants to sync to the active environment. I don't see a
compelling reason not to make opt-in easier. I see a lot of questions
about how to deal with this warning in the issue tracker, but it seems
painful to collect them here for posterity.
A notable behavior here — we'll treat this as equivalent to
`UV_PROJECT_ENVIRONMENT` so... if you point us to a valid virtual
environment that needs to be recreated for some reason (e.g., new Python
version request), we'll happily delete it and start over.
We regularly get questions why `uv build` is missing certain files or
using the wrong build tag, when that's done by the build backend and
part of the build backend's docs. I tried to clarify this difference and
to redirect users to look at the tool's docs instead of wondering why
uv's docs don't explain that.
---------
Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
I'm not sure if this should go in the CLI reference or not? but here
seems like an okay start. I want to figure out a way to avoid repeating
this content.
## Summary
The docs did mention that you could set the `UV_PROJECT_ENVIRONMENT`
variable to point Uv to use the system Python environment (e.g. for use
in CI or Docker), but it did not document _how_.
Reference:
https://github.com/astral-sh/uv/pull/6834#issuecomment-2319253359
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
<!--
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
<!-- What's the purpose of the change? What does it do, and why? -->
Fix invalid links in [configuring
projects](https://docs.astral.sh/uv/concepts/projects/config/#entry-points)
doc.
## Test Plan
<!-- How was it tested? -->
## Summary
Unless I'm doing something wrong, specifying `hatchling` as a build
system here results in `ValueError: Unable to determine which files to
ship`
## Test Plan
Following the instructions of the document.
## Additional
Don't hesitate to discard
## Summary
Since there are occasional inquiries about how to configure UV for
build-system specific features, I want to raise awareness that users
should refer to the documentation of the build system they are using for
relevant settings.
## Test Plan
Run docs service in local.
9821d58d35
---------
Signed-off-by: FishAlchemist <48265002+FishAlchemist@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Documentation steps resulted in errors due to single quotes when adding
project dependencies:
``` shell
>uv add 'httpx>0.1.0'
error: Failed to parse: `'httpx`
Caused by: Expected package name starting with an alphanumeric character, found `'`
'httpx
^
```
``` shell
>uv add 'PyQt5; sys_platform == "windows"
error: Failed to parse: `'PyQt5;`
Caused by: Expected package name starting with an alphanumeric character, found `'`
'PyQt5;
^
```
## Testing Steps
- Follow new documentation steps
Tested on:
- [x] Windows
Just a small note to say that dependencies between workspace members are
editable as shown in #9362
(This might be obvious since if dependencies between workspaces members
are not editable then every time a workspace member is update it has to
be manually reinstalled but since it's in the concepts documentation and
since I see a lot of issues about workspaces, that little note might
help newcomers a little bit)
