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
```
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
I used `uvx` to test my code using `pytest` it was just before the
documentation and it worked pretty fine. But when I saw the docs I was
confused as it says:
> If you are running a tool in a project and the tool requires that your
project is installed, e.g., when using `pytest` or `mypy`, you'll want
to use `uv` run instead of `uvx`. Otherwise, the tool will be run in a
virtual environment that is isolated from your project.
So to make it simple if you don't recommend using `uvx` in this
situation then here is the pull request, and if not just close this pull
request. I said that I don't have to open an issue to discuss this as
it's so simple.
## Test Plan
None
---------
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? -->
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
<!--
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.
## Summary
`mkdocs` supports [validation rules for
links](https://www.mkdocs.org/user-guide/configuration/#validation),
which can be tightened to report more issues than the default
configuration. I used the recommended "maximal strictness" configuration
from the documentation.
Adding the `anchors` rule helped spot 4 errors:
```console
WARNING - Doc file 'guides/install-python.md' contains a link '../concepts/python-versions.md#python-distributions', but the doc 'concepts/python-versions.md' does not contain an anchor '#python-distributions'.
WARNING - Doc file 'guides/install-python.md' contains a link '../concepts/python-versions.md#discovery-order', but the doc 'concepts/python-versions.md' does not contain an anchor '#discovery-order'.
WARNING - Doc file 'guides/projects.md' contains a link '../concepts/projects.md#lock-file', but the doc 'concepts/projects.md' does not contain an anchor '#lock-file'.
WARNING - Doc file 'pip/environments.md' contains a link '../concepts/python-versions.md#discovery-order', but the doc 'concepts/python-versions.md' does not contain an anchor '#discovery-order'.
```
## Test Plan
Local run of the documentation + `mkdocs build --strict`.
