Pass UV_EXTRA_INDEX_URL to docker build

[gesta81]

No description provided.

[tschm]

@gesta81, welcome to this project! Please have a look at the feedback of our brutal ci/cd (which may also need an update)

[gesta81]

@gesta81, welcome to this project! Please have a look at the feedback of our brutal ci/cd (which may also need an update)

Thank you.
If by feedback you mean the list of issues - none seem to relate to this...

Sorry original commit was missing a line - hopefully fixed now.

[tschm]

@HarryCampion @gesta81 I don't understand why we need to inject an environment variable as a secret into a docker image. Why would the extra_index_url be a secret in the first place? I understand it could be done like this but is this good practice? @gesta81 I am really sorry. I am not an expert and rarely use the extra_index_url at all. Please tell me I am wrong!

[HarryCampion]

@HarryCampion @gesta81 I don't understand why we need to inject an environment variable as a secret into a docker image. Why would the extra_index_url be a secret in the first place? I understand it could be done like this but is this good practice? @gesta81 I am really sorry. I am not an expert and rarely use the extra_index_url at all. Please tell me I am wrong!

UV_EXTRA_INDEX_URL might contain a PAT to the artifact feed. My preference here is we go with uv auth login as a way of authentication and users should either pass a token or have it as an env var. If your uv lock contains references to artefacts that need authentication such as an ADO artifact feed or Jfrog then you need a way to pass this authentication.

I am not overly keen on passing round UV_EXTRA_INDEX_URL as it can cause some unwanted side effects but not sure if we are able to make use of uv auth login in GitHub workflows. The preference is to always be very explicit in the pyproject.toml about where the package is coming from if not pypi. See below

[tool.uv.sources]
torch = { index = "pytorch" }

[[tool.uv.index]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cpu"

https://docs.astral.sh/uv/concepts/indexes/#defining-an-index

Oh and yes welcome @gesta81 😄!

[HarryCampion]

@HarryCampion @gesta81 I don't understand why we need to inject an environment variable as a secret into a docker image. Why would the extra_index_url be a secret in the first place? I understand it could be done like this but is this good practice? @gesta81 I am really sorry. I am not an expert and rarely use the extra_index_url at all. Please tell me I am wrong!

So an example might be that your docker build fails because your uv.lock is referencing a package from a private feed. The build will use uv sync --frozen to guarantee runtime conditions but if the artifact feed is not reachable due to a token not being present in the context then the build will fail.

[tschm]

Sounds to me you should first experiment with uv auth login. Do you have a problem at hand for this? I see the Dockerfile as some example. More advanced users can use their very own version and do not update using rhiza. So let's not go too wild