## Summary
Adds an IPA pronunciation to the very top of the README, for the sake of
clarity. This is a minor thing, but it's nice to know that there's a
'standard' pronunciation for uv.
I have no idea whether this will seem like a "reasonable" place to put
this; I looked over the README and didn't see any obviously more
appropriate places to put it. Maybe this is unobtrusive enough that it's
fine where it is; maybe there should be a new section added somewhere;
maybe somebody who has a better feel for the project goals will have a
clever suggestion.
Closes#5309
---------
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
I've just fixed some broken anchors after browing ux doc site.
## Test Plan
- `index.md`: based on `mkdocs serve` log
- `readme.md`: manual check
## Aside
Do you manually keep `readme.md` and `index.md` partially sync? I've
tried
checking pre-commit and other scripts but found no way to port my edits
from one
to the other.
<!-- How was it tested? -->
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
- Broke up the large code block into 3 blocks so that copy paste icon
works
Howdy Astral friends! This is a small PR which is a small user
experience improvement for smooth installs.
<!--
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? -->
## 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 README contains a link to the publish guide
(https://docs.astral.sh/uv/guides/publish.md) that gives an error 404.
When navigating to that page via the side menu, the correct link seems
to be (https://docs.astral.sh/uv/guides/publish/).
## Test Plan
<!-- How was it tested? -->
Documentation change, therefore manual testing by clicking on the link.
## Summary
This PR aims to align the instructions for installing the Windows
standalone installer in the README with the current documentation.
7bd0d97ce5/docs/getting-started/installation.md?plain=1#L17-L21
## Test Plan
Only README is modified and identical to the doc, so not tested.
## Summary
Explicitly list the formats and extensions that uv supports, based on
[this
list](86ee8d2c01/crates/distribution-filename/src/extension.rs (L70-L77)).
Not a huge fan of adding the section in `concepts/resolution.md`, but I
did not find a better place. Alternatively we could maybe add a
dedicated page that shortly explains Python package types (wheels,
sdists), where such a section could live?
## Test Plan
Local run of the documentation.
<!--
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 think it's important to clarify that `uvx` is simply an alias for `uv
tool run`. This distinction helps avoid confusion about when to use `uv`
versus `uvx`. I thought the [blog
post](https://astral.sh/blog/uv-unified-python-packaging) explained this
well.
Just something that I ran into, I understand others may have a different
perspective!
## Test Plan
n/a
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
This PR migrates uv's use of `chrono` to `jiff`.
I did most of this work a while back as one of my tests to ensure Jiff
could actually be used in a real world project. I decided to revive
this because I noticed that `reqwest-retry` dropped its Chrono
dependency,
which is I believe the only other thing requiring Chrono in uv.
(Although, we use a fork of `reqwest-middleware` at present, and that
hasn't been updated to latest upstream yet. I wasn't quite sure of the
process we have for that.)
In course of doing this, I actually made two changes to uv:
First is that the lock file now writes an RFC 3339 timestamp for
`exclude-newer`. Previously, we were using Chrono's `Display`
implementation for this which is a non-standard but "human readable"
format. I think the right thing to do here is an RFC 3339 timestamp.
Second is that, in addition to an RFC 3339 timestamp, `--exclude-newer`
used to accept a "UTC date." But this PR changes it to a "local date."
That is, a date in the user's system configured time zone. I think
this makes more sense than a UTC date, but one alternative is to drop
support for a date and just rely on an RFC 3339 timestamp. The main
motivation here is that automatically assuming UTC is often somewhat
confusing, since just writing an unqualified date like `2024-08-19` is
often assumed to be interpreted relative to the writer's "local" time.
## Summary
This PR adds descriptions for the `UV_TOOL_DIR`, `UV_PYTHON_INSTALL_DIR`
and `XDG_*` environment variables.
Additionally, it moves some env vars that are not command-line arguments
to the below "uv respects" section.
Closes#5746
This PR rewrites the resolver concept and adds a resolver internals page
targeted at power users.
The new resolution concept documentation has three parts:
* An introduction for people how never heard of "resolution" before, and
a motivating example what it does. I've also shoved the part about
equally valid resolutions in there.
* Features you commonly use: Non-universal vs. universal resolution,
lowest resolution amd pre-releases.
* Expert features, we don't advertise them, you'll only need them in
complex cases when you already know and i kept them to the reference
points you need in this case: Constraints, overrides and exclude-newer.
I intentionally didn't lay out any detail of the resolution itself, the
idea is that users get a vague sense of "uv has to select fitting
versions", but then they learn the options they have to use and some
common failure points without ever coming near SAT or even graphs.
The resolution internals reference page is targeted at power users who
need to understand what is going on behind the scenes. It assumes ample
prior knowledge and exists to explain the uv-specific behaviors for
someone who already understands dependency resolution conceptually and
has interacted with their dependency tree before. I had a section on the
lockfile but removed it because it found the lockfile to be too
self-documenting.
I haven't touched the readme.
Closes#5603Closes#5238Closes#5237
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
To enforce the 100 character line limit in markdown files introduced in
https://github.com/astral-sh/uv/pull/5635, and to automate the
formatting of markdown files, i've added prettier and formatted our
markdown files with it.
I've excluded the changelog and the generated references documentation
from this for having too many changes, but we can also include them.
I'm not particular on which style we use. My main motivations are
(major) not having to reflow markdown files myself anymore and (minor)
consistence between all markdown files. I've chosen prettier for similar
reason as we chose black, it's a single good style that's automated and
shared in the community. I do prefer prettier's style of not breaking
inside of a link name though.
This PR is in two parts, the first adds prettier to CI and documents
using it, while the second actually formats the docs. When merge
conflicts arise, we can drop the last commit and regenerate it with `npx
prettier --prose-wrap always --write BENCHMARKS.md CONTRIBUTING.md
README.md STYLE.md docs/*.md docs/concepts/**/*.md docs/guides/**/*.md
docs/pip/**/*.md`.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Partially resolves#5561. Haven't added overrides support yet but I can
add it tomorrow if the current approach for constraints is ok.
## Test Plan
`cargo test`
Manually checked trace logs after changing the constraints.
## Summary
This PR deprecates the `--isolated` flag. The treatment varies across
the APIs:
- For non-preview APIs, we warn but treat it as equivalent to
`--no-config`.
- For preview APIs, we warn and ignore it, with two exceptions...
- For `tool run` and `run` specifically, we don't even warn, because we
can't differentiate the command-specific `--isolated` from the global
`--isolated`.
Zanie Blue
konsti
Peter Gaultney
Tai
Charlie Marsh
Carol Willing
Lan, Jian
Andi Pabst
AC
Aditya Pratap Singh
FishAlchemist
Mathieu Kniewallner
Boris Verkhovskiy
Sergey Filimonov
Andrew Gallant
Jo
Ahmed Ilyas