Feature Request: @fal.function(kind="uv_venv") as alternative to "virtualenv"

[anthonywu]

I noticed the pip install steps of @fal.function was slower than I'd expect it to run on data center bandwidth and caching.

fal/projects/fal/src/fal/api.py

Line 678 in bc14436

kind: Literal["virtualenv"] = "virtualenv",

def function(
    kind: Literal["virtualenv"] = "virtualenv",  # expand this to include 'uv venv' and then 'uv pip install...'

Modal recently introduced https://modal.com/docs/reference/modal.Image#uv_pip_install which is really nice.

The success criteria would be:

1. for all usages uv_venv and virtualenv should have no functional or package solver difference, just that fal would benefit from uv performance gains.
2. Fal's backend should have some sort of background cache for uv (https://docs.astral.sh/uv/concepts/cache/#caching-in-continuous-integration), so that even when the user is not trying to cache, the upstream index/wheels are coming from a fast local cache that uv uses (some sort of mount that user can readonly)

Alternatively, perhaps users can submit our own installation scripts to be run, and from that we can setup the venv with whatever we want (uv, poetry, hatch, tox, anything from the ecosystem)

As far as I can tell, the fal repo does not encompass the server side implementation of the "virtualenv" step, so I think the change cannot be contributed in open source alone.

[efiop]

Hey @anthonywu , we actually use uv by default, unless you use resolver=None parameter.

[anthonywu]

Is there robust buildkit cache mounting for pypi caching going on between repeated image builds during rapid iteration? Or maybe the depot builds are going to diff machines so there's no cache benefit. If uv starts fresh every time I expect no performance improvement. I saw depot was the build provider, would love additional flags to proxy to depot access any advanced features.

I'll study this again and compare to other remote build providers. Will close issue for now.

[efiop]

@anthonywu we don't cache pypi across runs, that is true. I think we could definitely cache it, possibly by mounting /data like we do for runtime but for env builds. We can def look into that. Reopening for that

[anthonywu]

I would totally be OK if the cache is timed out after a reasonable period.

[anthonywu]

https://depot.dev/docs/container-builds/overview#persistent-shared-caching

it seems like the Depot team has considered this optimization upstream:

We automatically persist your Docker layer cache to fast NVMe storage and make it instantly available across builds. The layer cache is also shared across your entire team with access to the same project, so you can also benefit from your team's work.