## Summary
The [current scripts docs
page](https://docs.astral.sh/uv/guides/scripts/) doesn't include detail
on how to use a custom package index when setting up a script. I believe
this might be because it didn't use to work (see #6688 ) but it now does
(thanks for that, by the way! 😄)
Given it's a useful feature, I suggest adding a quick example to the
scripts page, with the details of authentication, etc. left to the main
`indexes.md` doc.
I'd also suggests that this closes#6688, though it doesn't actually add
that feature - that appears to have already been done :)
## Test Plan
No testing is needed, I think!
---------
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">
This PR adds support for ```uv init --script```, as defined in issue
#7402 (started working on this before I saw jbvsmo's PR). Wanted to
highlight a few decisions I made that differ from the existing PR:
1. ```--script``` takes a path, instead of a path/name. This potentially
leads to a little ambiguity (I can certainly elaborate in the docs,
lmk!), but strictly allowing ```uv init --script path/to/script.py```
felt a little more natural than allowing for ```uv init --script path/to
--name script.py``` (which I also thought would prompt more questions
for users, such as should the name include the .py extension?)
2. The request is processed immediately in the ```init``` method,
sharing logic in resolving which python version to use with ```uv add
--script```. This made more sense to me — since scripts are meant to
operate in isolation, they shouldn't consider the context of an
encompassing package should one exist (I also think this decision makes
the relative codepaths for scripts/packages easier to follow).
3. No readme — readme felt a little excessive for a script, but I can of
course add it in!
---------
Co-authored-by: João Bernardo Oliveira <jbvsmo@gmail.com>
As a non-shell-wizard, I was unfamiliar with the `EOF` syntax used in
the existing example (just above the one I added). I thought including
an example where the output of `echo` is piped to `uv run` might be more
accessible. As a bonus, it should work across more shells: the `EOF`
example doesn't work in fish because fish [doesn't support
heredocs](https://fishshell.com/docs/current/fish_for_bash_users.html#heredocs),
while the `echo` example does.
Feel free to ignore if unwanted.
<!--
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? -->
Document in guide stdin usage
alllll the easter eggs can do as well, but declined to keep consistent
with the other examples 😆
Additions to https://github.com/astral-sh/uv/pull/6481
```bash
$ uv run - <<EOF
import antigravity
EOF
```
## Test Plan
<!-- How was it tested? -->
https://github.com/astral-sh/uv/pull/6519#issuecomment-2307371063 new PR
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
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`.
Moving the preview features to top-level concepts and pushing the
pip-compatible interface down.
e.g.
<img width="291" alt="Screenshot 2024-06-27 at 7 03 48 AM"
src="500ad97d-899d-4051-b59d-e74786b3a45f">
