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