- 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
Now that we have all the pieces in place, this PR adds some dedicated
documentation to enable a variety of PyTorch setups.
This PR is downstream of #6523 and builds on the content in there; #6523
will merge first, and this PR will follow.
Hello there! First real docs PR for uv.
1. I expect this will be rewritten a gazillion times to have a
consistent tone with the rest of the docs, despite me trying to stick to
it as best as I could. Feel free to edit!
2. I went super on the verbose mode, while also providing a callout with
a TLDR on top. Scrap anything you feel it's redundant!
3. I placed the guide under `integrations` since Charlie added the
FastAPI integration there.
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
Addresses #5945
## Test Plan
<!-- How was it tested? -->
I just looked at the docs on the dev server of mkdocs if it looked nice.
**I could not test the commands that I wrote work** outside of macOS. If
someone among contributors has a Windows/Linux laptop, it should be
enough, even for the GPU-supported versions: I expect the installation
will just break once torch checks for CUDA (perhaps even at runtime).
---------
Co-authored-by: Santiago Castro <bryant1410@gmail.com>
Co-authored-by: Charlie Marsh <charlie.r.marsh@gmail.com>
## Summary
This commit adds Google Artifact Registry authentication instructions
for both basic HTTP authentication and keyring methods.
## Test Plan
Locally tested using both methods.
## Summary
Renovate recently gained support for updating dependencies defined using
PEP 723 (https://github.com/renovatebot/renovate/pull/31266). Since uv
supports this format, I thought it could be nice to mention support for
it in the integrations documentation as well. I took the occasion to
make the page a bit more structured as well.
## Test Plan
Ran Renovate on https://github.com/mkniewallner/renovate-pep723, which
created https://github.com/mkniewallner/renovate-pep723/pull/2 that
updates a dependency defined using PEP 723. But I'll re-run some tests
again once the changes are released on Renovate cloud GitHub app just in
case.
<!--
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
Documentation for GitLab integration, reliant on the new tags introduced
in https://github.com/astral-sh/uv/pull/6053
## Test Plan
<!-- How was it tested? -->
---------
Co-authored-by: David Fritzsche <9479371+davidfritzsche@users.noreply.github.com>
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
It was all too easy to just copy the non-qualified name of the Docker
images and wonder why they couldn't be found – well, because they're on
`ghcr.io`, and you need to read the prose before the list to figure that
out.
## Test Plan
No plan.
## Summary
Related discussion: #5731
This adds a warning section for caching on non-ephemeral (e.g. ec2) self
hosted github runners.
## Test Plan
Prettier was ran on the file.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
## Summary
Update the extended docker example to use bind mounts and avoid creating
extra layers and avoid copying files into layers
This is in line with the official Docker templates for Python
applications (you can try them out using `docker init`. I found them
very helpful!)
## Summary
Closes https://github.com/astral-sh/uv/issues/5610
This PR introduces additional images with the uv/uvx binaries from
scratch for both amd64/arm64 and make the mapping easy to configure by
generating the Dockerfile on the fly. This approach focuses on
minimizing CI time by taking advantage of dedicating a worker per
mapping (20-30s~ per job).
This PR also fixes `org.opencontainers.image.version` for all tags
(including the one from `scratch) to contain the right release version
instead of branch name `main` (default when no tag patterns are
specified).
For example, on release `x.y.z`, this will publish the following image
tags with format `ghcr.io/astral-sh/uv:{tag}` with manifests for both
amd64/arm64. This also include `x.y` tags for each respective additional
tag.
* From **scratch**: `latest`, `x.y.z`, `x.y` (currently being published)
* From **alpine:3.20**: `alpine`, `alpine3.20`, `x.y.z-alpine`,
`x.y.z-alpine3.20`
* From **debian:bookworm-slim**: `debian-slim`, `bookworm-slim`,
`x.y.z-debian-slim`, `x.y.z-bookworm-slim`
* From **buildpack-deps:bookworm**: `debian`, `bookworm`,
`x.y.z-debian`, `x.y.z-bookworm`
* From **python:3.12-alpine**: `python3.12-alpine`,
`x.y.z-python3.12-alpine`
* From **python:3.11-alpine**: `python3.11-alpine`,
`x.y.z-python3.11-alpine`
* From **python:3.10-alpine**: `python3.10-alpine`,
`x.y.z-python3.10-alpine`
* From **python:3.9-alpine**: `python3.9-alpine`,
`x.y.z-python3.9-alpine`
* From **python:3.8-alpine**: `python3.8-alpine`,
`x.y.z-python3.8-alpine`
* From **python:3.12-bookworm**: `python3.12-bookworm`,
`x.y.z-python3.12-bookworm`
* From **python:3.11-bookworm**: `python3.11-bookworm`,
`x.y.z-python3.11-bookworm`
* From **python:3.10-bookworm**: `python3.10-bookworm`,
`x.y.z-python3.10-bookworm`
* From **python:3.9-bookworm**: `python3.9-bookworm`,
`x.y.z-python3.9-bookworm`
* From **python:3.8-bookworm**: `python3.8-bookworm`,
`x.y.z-python3.8-bookworm`
* From **python:3.12-slim-bookworm**: `python3.12-slim-bookworm`,
`x.y.z-python3.12-slim-bookworm`
* From **python:3.11-slim-bookworm**: `python3.11-slim-bookworm`,
`x.y.z-python3.11-slim-bookworm`
* From **python:3.10-slim-bookworm**: `python3.10-slim-bookworm`,
`x.y.z-python3.10-slim-bookworm`
* From **python:3.9-slim-bookworm**: `python3.9-slim-bookworm`,
`x.y.z-python3.9-slim-bookworm`
* From **python:3.8-slim-bookworm**: `python3.8-slim-bookworm`,
`x.y.z-python3.8-slim-bookworm`
## Summary
- Fixed the directory structure and commands for the second scenario
#6833
- Added a headline "Migrating an existing FastAPI project" because the
first part looks like a migration scenario, but didn't have its own
section before.
- Added explicit `--app` flags to commands to emphasize that the
commands create an Application project. Although maybe unnecessary
considering that `--app` is now default.
- Added instructions for testing that the dev server and Docker image
work correctly
- Took the liberty of adding a `project` at the root of all directory
structures and appropriate commands.
- With explicitly defined root directory it is easier to differentiate
between the `project` root directory and FastAPI's `app` directory.
- Without it it could be less obvious for developers less familiar with
FastAPI. Had a similar issue when started using Django several years
ago.
- If I left `app` in the command, then after copying the **app
directory** from https://github.com/astral-sh/uv-fastapi-example the
path would be `app/app/...`.
- Cleaned up glyphs in tree sctructures that were copied from FastAPI
docs.
## Caveats
- On project initialization `hello.py` is created. It is not reflected
in directory structure trees in this PR and may be slightly confusing
for developers less familiar with uv.
- I believe it will be soon addressed in #6750 and after that the docs
will reflect actual directory structure.
<!--
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
This adds explicit information about using `uv` with AWS CodeArtifact
(both as an extra index to fetch private packages and also to publish
packages using `twine`).
## Test Plan
I'm currently using this setup with several private projects that use
CodeArtifact.
---------
Co-authored-by: Zanie Blue <contact@zanie.dev>
When not using a python base image and using alpine, you need to install
python by yourself. You should also pin the python version when doing
so; currently, i see only python 3.12 in the alpine repository.
<!--
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 following Dockerfile command fails:
```
[...]
RUN --mount=from=uv,source=/uv,target=/bin/uv \
cd /opt/opencti-connector-webhook && \
uv pip install --system -r requirements.txt && \
apk del git build-base
[...]
```
Result
```
yo@opencti:~/connectors/stream/webhook$ docker build -t opencti/connector-webhook:d .
[+] Building 1.0s (3/3) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.1s
=> => transferring dockerfile: 557B 0.1s
=> ERROR [internal] load metadata for docker.io/library/uv:latest 0.8s
=> [internal] load metadata for docker.io/library/python:3.11-alpine 0.8s
------
> [internal] load metadata for docker.io/library/uv:latest:
------
ERROR: failed to solve: uv: failed to resolve source metadata for docker.io/library/uv:latest: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
```
Fix:
```
[...]
RUN --mount=from=ghcr.io/astral-sh/uv,source=/uv,target=/bin/uv \
cd /opt/opencti-connector-webhook && \
uv pip install --system -r requirements.txt && \
apk del git build-base
[...]
```
## Test Plan
<!-- How was it tested? -->
```
$ docker --version
Docker version 26.0.0, build 2ae903e
$ date
Mon Aug 26 20:31:53 UTC 2024
$ docker build -t opencti/connector-webhook:e .
[+] Building 41.8s (13/13) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 587B 0.0s
=> [internal] load metadata for ghcr.io/astral-sh/uv:latest 0.5s
=> [internal] load metadata for docker.io/library/python:3.11-alpine 0.5s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.0s
=> [stage-0 1/6] FROM docker.io/library/python:3.11-alpine@sha256:700b4aa84090748aafb348fc042b5970abb0a73c8f1b4fcfe0f4e3c2a4a9fcca 0.0s
=> [internal] load build context 0.1s
=> => transferring context: 130B 0.0s
=> CACHED FROM ghcr.io/astral-sh/uv:latest@sha256:f6b18f4a7408c5244374b00c8832089258d130f7a77a38807348072e714ffa0c 0.0s
=> CACHED [stage-0 2/6] COPY src /opt/opencti-connector-webhook 0.0s
=> CACHED [stage-0 3/6] RUN apk --no-cache add git build-base libmagic libffi-dev libxml2-dev libxslt-dev 0.0s
=> [stage-0 4/6] RUN --mount=from=ghcr.io/astral-sh/uv,source=/uv,target=/bin/uv cd /opt/opencti-connector-webhook && uv pip install --system -r requirements.txt 38.3s
=> [stage-0 5/6] COPY entrypoint.sh / 0.1s
=> [stage-0 6/6] RUN chmod +x /entrypoint.sh 0.8s
=> exporting to image 1.7s
=> => exporting layers 1.6s
=> => writing image sha256:aa6810f883d104c838f35e848c0d7d8b4df5c7c3929f18a88b7139d0ec892a0b 0.0s
=> => naming to docker.io/opencti/connector-webhook:e 0.0s
```
<!--
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
Two small typo fixes: one in the documentation and one in a comment in
the source code I happened to come across.
<!--
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? -->
Updated docs dockerfile from Debian 11 (bullseye) to latest stable
Debian 12 (bookworm).
## Test Plan
<!-- How was it tested? -->
A dockerfile using `ubuntu` instead of `python` as base image currently
silently fails to install.
```dockerfile
FROM ubuntu
RUN apt-get update && apt-get install -y curl --no-install-recommends
RUN curl -LsSf https://astral.sh/uv/install.sh | sh
RUN uv --version
```
```console
$ docker buildx build --progress plain --no-cache .
[...]
#6 [3/4] RUN curl -LsSf https://astral.sh/uv/install.sh | sh
#6 0.144 curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
#6 DONE 0.2s
#7 [4/4] RUN uv --version
#7 0.113 /bin/sh: 1: uv: not found
#7 ERROR: process "/bin/sh -c uv --version" did not complete successfully: exit code: 127
```
There's two underlying problems: Pipefail, and missing
`ca-certificates`.
In most shells, the source of a pipe erroring doesn't fail the entire
command, so `curl -LsSf https://astral.sh/uv/install.sh | sh` passes
even if the curl part fails. In bash, you can prefix the command with
`set -o pipefail &&` to change this behavior. But in the `ubuntu` docker
container, dash is the default shell, not bash. dash doesn't have a
pipefail option (in the version in ubuntu), so the [best
practice](https://docs.docker.com/build/building/best-practices/#using-pipes)
is `RUN ["/bin/bash", "-c", "set -o pipefail && curl -LsSf
https://astral.sh/uv/install.sh | sh"]`. That's not very readable, so
i'm going for `RUN curl -LsSf https://astral.sh/uv/install.sh >
/tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm
/tmp/uv-installer.sh` instead.
```dockerfile
FROM ubuntu
RUN apt-get update && apt-get install -y curl --no-install-recommends
RUN curl -LsSf https://astral.sh/uv/install.sh > /tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm /tmp/uv-installer.sh \
RUN uv --version
```
```console
$ docker buildx build --progress plain --no-cache .
[...]
#6 [3/3] RUN curl -LsSf https://astral.sh/uv/install.sh > /tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm /tmp/uv-installer.sh RUN uv --version
#6 0.179 curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt
#6 ERROR: process "/bin/sh -c curl -LsSf https://astral.sh/uv/install.sh > /tmp/uv-installer.sh && sh /tmp/uv-installer.sh && rm /tmp/uv-installer.sh RUN uv --version" did not complete successfully: exit code: 77
```
The source for this error is `ca-certificates` missing, which is a
recommended package. We need to drop `--no-install-recommends` and the
installation passes again.
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>