Python Manager in Frappe Docker

[adithyaappu]

As far as I understood, the bench now uses uv as python version and package manager. It is added as a dependency for bench
https://github.com/frappe/bench/blob/5107f1df45eb5f780a54073d027cab7442a39b46/pyproject.toml#L31C1-L31C17

Docker images in this repo uses pyenv, as seen here,
https://github.com/frappe/frappe_docker/blob/99d9a1dc385d8a0660a67b0cbbfeac3d5229e58c/images/bench/Dockerfile#L101C1-L105C49

I think this is going to create conflicts, as both are trying to manage the python version.

My suggestions,

1. Images should be migrated to uv, since it is a hard dependency by bench. So remove the pyenv from Dockerfile.
2. Version and Python environment must be set with uv instead of pyenv.

[DanielRadlAMR]

I'm not quite sure if this will work with the current setup. Right now, the container has two different Python versions to maintain compatibility with older Frappe versions (v15). I'm not certain if Bench’s uv support allows managing multiple Python versions without pyenv; it might just assume a single Python version is available.

Perhaps we should consider splitting the Dockerfile into two separate ones: one for the current Frappe version and one for the previous version. Having both Python versions in a single container seems unnecessary since, in most cases, you'd only need one. With separate containers, users could simply choose the one that fits their setup, reducing overhead and complexity.

I might be missing some of the finer technical details of pyenv vs uv, so feedback from someone more familiar would be helpful.

[adithyaappu]

uv can manage multiple Python versions. It calls the Python version installed by uv as managed Python installations. For example,

uv python install 3.12.3

will install this specific version. More here.

Compared to pyenv the installation is nearly instantaneous, since uv uses pre-built CPython binaries from Astral's repo. Of course it has it's own quirks, as the compilation is not done on the system, like pyenv do. More info.

Similar to pyenv, uv can pin a specific version at different levels. It uses a .python-version file for this.

[DanielRadlAMR]

So, are you saying it should be a drop-in replacement?

What’s your opinion on keeping older dependencies in a single image versus splitting different dependency versions into separate images?

[DanielRadlAMR]

#1792

[adithyaappu]

Sorry for going being absconding for long periods. Dealing with a lot of stuff now. Did you mean creating two images, where one is for versions before uv was introduced, and the other for the versions after uv was introduced?

[DanielRadlAMR]

@adithyaappu no worries—happy to hear from you whenever you have the time, but there’s no pressure 🙂

I meant separating the different Frappe versions. Right now, the image supports the two latest versions (v16 and v15) by installing dependencies for both (i.e., two different Python and Node versions in a single image).
My idea was to split this into two images: one supporting only v16 and the other only v15.

If uv truly is a drop-in replacement, there shouldn’t be any need to keep images from before it was introduced, right?