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)
## Summary
This PR fixes name of `--refresh-package` flag in cache docs. It's
misspelled as `--refresh-dependency`.
## Test Plan
Deployed docs locally.
This is a first-pass at updating the "Managing dependencies" page after
moving some of the project concept documentation into it. I want to do
more things, like improve visibility into upgrading packages and
reordering some sections, but will tackle those separately for review.
The primary goals here were to consolidate redundant information on
dependency tables and improve the consistency of examples.
The snippet out of context looks like a valid minimal pyproject.toml
which it is not without name and version. The line worked in layout.md
before when it was just under the minimal config.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
- Adds a collapsible section for the project concept
- Splits the project concept document into several child documents.
- Moves the workspace and dependencies documents to under the project
section
- Adds a mkdocs plugin for redirects, so links to the moved documents
still work
I attempted to make the minimum required changes to the contents of the
documents here. There is a lot of room for improvement on the content of
each new child document. For review purposes, I want to do that work
separately. I'd prefer if the review focused on this structure and idea
rather than the content of the files.
I expect to do this to other documentation pages that would otherwise be
very nested.
The project concept landing page and nav (collapsed by default) looks
like this now:
<img width="1507" alt="Screenshot 2024-11-14 at 11 28 45 AM"
src="https://github.com/user-attachments/assets/88288b09-8463-49d4-84ba-ee27144b62a5">
## Summary
This PR enables something like the "final boss" of PyTorch setups --
explicit support for CPU vs. GPU-enabled variants via extras:
```toml
[project]
name = "project"
version = "0.1.0"
requires-python = ">=3.13.0"
dependencies = []
[project.optional-dependencies]
cpu = [
"torch==2.5.1+cpu",
]
gpu = [
"torch==2.5.1",
]
[tool.uv.sources]
torch = [
{ index = "torch-cpu", extra = "cpu" },
{ index = "torch-gpu", extra = "gpu" },
]
[[tool.uv.index]]
name = "torch-cpu"
url = "https://download.pytorch.org/whl/cpu"
explicit = true
[[tool.uv.index]]
name = "torch-gpu"
url = "https://download.pytorch.org/whl/cu124"
explicit = true
[tool.uv]
conflicts = [
[
{ extra = "cpu" },
{ extra = "gpu" },
],
]
```
It builds atop the conflicting extras work to allow sources to be marked
as specific to a dedicated extra being enabled or disabled.
As part of this work, sources now have an `extra` field. If a source has
an `extra`, it means that the source is only applied to the requirement
when defined within that optional group. For example, `{ index =
"torch-cpu", extra = "cpu" }` above only applies to
`"torch==2.5.1+cpu"`.
The `extra` field does _not_ mean that the source is "enabled" when the
extra is activated. For example, this wouldn't work:
```toml
[project]
name = "project"
version = "0.1.0"
requires-python = ">=3.13.0"
dependencies = ["torch"]
[tool.uv.sources]
torch = [
{ index = "torch-cpu", extra = "cpu" },
{ index = "torch-gpu", extra = "gpu" },
]
[[tool.uv.index]]
name = "torch-cpu"
url = "https://download.pytorch.org/whl/cpu"
explicit = true
[[tool.uv.index]]
name = "torch-gpu"
url = "https://download.pytorch.org/whl/cu124"
explicit = true
```
In this case, the sources would effectively be ignored. Extras are
really confusing... but I think this is correct? We don't want enabling
or disabling extras to affect resolution information that's _outside_ of
the relevant optional group.
This doesn't cover the optional `package` key since I wasn't quite sure
how to articulate its utility in a digestible way.
---------
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? -->
Update `resolution` to `--resolution`, so it's aligned with the rest of
the resolution documentation, and copy-pastable for usage.
---------
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
