Support `pip download`

[idlsoft]

This would be especially useful for buildng docker images.

You could then rely on uv for a quick resolve and use a simple pip install --no-deps --find-links in your Dockerfile.

[samypr100]

This is along the similar lines of supporting pip wheel discussed in #1681

[inoa-jboliveira]

Hi everyone, is this feature on the roadmap? I am guessing supporting "pip download" would be straightforward since uv already downloads packages. It would just have to not install them.

Any help needed?

[charliermarsh]

We should be able to support it... Though it's not trivial because we don't store the .whl files at all, we unzip them directly into the cache. So most of the data pipelines are oriented around an API that receives the unzipped wheel, rather than the zipped wheel.

What are the typical use-cases here?

[idlsoft]

What are the typical use-cases here?

In my case it's a docker build in a github workflow.

Caching docker layers on github runners is impossible AFAIK. Caching ~/.cache is trivial.
So a build could download whls into the docker working dir, then do

COPY whls whls
RUN pip install --no-deps --find-links whls ....

Which wouldn't hit pypi and wouldn't need any additional caching from docker.

... This can be even better if you can do RUN --mount ...

[charliermarsh]

I'm mostly wondering if it has to be wheels or if we could just make it easy to pre-populate the uv cache.

[idlsoft]

I'm mostly wondering if it has to be wheels or if we could just make it easy to pre-populate the uv cache.

wheels are supported by standard pip install.
Otherwise you need to use uv inside docker build. Not bad necessarily, but a bit less flexible.

[zanieb]

I'm not sure how much we should go out of our way to support using pip to consume an output of uv? It seems weird to use uv in one case and pip in another, right?

[charliermarsh]

If it were equally easy for us I'd probably prefer to output wheels, it's a nicer intermediary format that's less coupled to our internal cache. I'd need to see how hard it is to support.

[inoa-jboliveira]

What are the typical use-cases here?

Hi, my use case is that I have to supply bundles of my application with all dependencies for systems where it is not possible to download them (firewall blocking). Right now I use pip download which results in a bunch of wheel files.

Also we would like to be able to cross platform download them too

[charliermarsh]

That makes sense, thanks.

[idlsoft]

I'm not sure how much we should go out of our way to support using pip to consume an output of uv? It seems weird to use uv in one case and pip in another, right?

That part of the workflow may not be entirely under your control.
@inoa-jboliveira's example is a better one I think, because it's essentialy about packaging your application.
Packaging may need to comply with a specific post-install procedure.

[samypr100]

Right now I use pip download which results in a bunch of wheel files.

Note, both pip download and pip wheel are similar but there's crucial differences. If you're looking to package up your wheels, pip wheel is often recommended instead since it covers for cases where a download does not have a pre-built wheel, being a more complete solution to pre-packaging wheels for a target system.

As a result, I tend to just always use pip wheel nowadays to make sure I always have wheels rather than potential source distributions that I'll have to build on the target system. From my perspective, pip download is more useful when you want to package up sdists or when you don't care if everything you download is fully pre-built.

Some of these tradeoffs were actually discussed in #1681.

[inoa-jboliveira]

Hi @samypr100 in this specific case I really just want to download pre built wheels and not build anything. I can pip download --platform foo and I am good to go. That's why I need and still use pip download.

As for pip wheel, I can't cross platform download (nor compile) anything