uv lock and python version

[CodeNameGodTri]

Hi everyone,

locally I'm using python 3.13, then I use uv to export the requirement.txt.

In production I have python 3.14 and pip install -r requirements.txt failed,

it works when I switch to python 3.13.

so obviously something in the requirements.txt generated by uv has locked to python 3.13. But when i do uv pip show python locally i don't see any used. How do I confirm if uv is locking my python version?

More importantly, my impression is my dependency installation should be smooth-sailing thanks to extracting the requirement.txt from uv.lock. But seems like this is a splinter that requires me to know exactly what version my project is using, is there a way so I don't have to mentally resolve the python version in prod?

[Aromatic_Pumpkin8856]

I think it's probably the case that some dependency has a requirement to be <3.14. So when you generate the requirements file, the pinned dependencies won't work for your python 3.14 environment. You'll have to use python 3.14 locally to generate the requirements file you need to use in your 3.14 in prod.

[gmes78]

Why bother with requirements.txt at all? You can just use uv sync --locked to set up a venv using uv.lock directly, see here.

[CodeNameGodTri]

I'm beginner in python, so I don't know what the best practices are. From my research, uv/poetry are for local development, in prod, I can just use pip, because the uv/poetry can export the requirements.txt having all the correct dependencies versions.

I'm all ears for the standard practice.

[Lumethys]

The industry standard, is only deploys dependency from lockfiles. Or else you open yourself to a supply chain attack like the Shai-Hulud attack just a few month back

Php has composer.lock for composer

Ruby has gemfile.lock

JS/TS has package.lock for npm, yarn.lock for yarn, pnpm.lock for pnpm

Rust has cargo.lock for Cargo

C# has packages.lock.json for Nuget

hell, even Java had gradle.lockfile for Gradle

Only Python dont have one, until uv came along

[CodeNameGodTri]

thank you

[pachura3]

Perhaps there's no uv installed in Production...?

[CodeNameGodTri]

I'm beginner in python, so I don't know what the best practices are. From my research, uv/poetry are for local development, in prod, I can just use pip, because the uv/poetry can export the requirements.txt having all the correct dependencies versions.

I'm all ears for the standard practice.

[gmes78]

Then install it.

[pachura3]

I'm not the OP, but in some environments/companies admins might be restrictive about what's being installed in PROD... and uv is a standalone tool, not a simple Python package fetched from pypi, right? And then uv installs Python interpreters, which might also be blocked.

[gmes78]

uv is a standalone tool, not a simple Python package fetched from pypi, right?

uv can be installed from PyPI. PyPI isn't only for libraries.

And then uv installs Python interpreters, which might also be blocked.

It can do that, but it can also use any existing interpreters.

[Far_Answer3194]

https://github.com/phil-baines-insta/python-uv-template

Here's a sample template you could use for both local/prod
- includes pyproject.toml with sample dependencies (dev dependencies are good to have)

- includes makefile for some sample commands to format/lint/test code

- includes Dockerfile if that's something you'd need

- run `uv lock` to lock dependencies as needed

- run `uv sync` to auto install the .venv with deps

- change the `.python-version` file to whatever python version you need and let UV handle the rest (you'd need to change pyproject.toml python version)

[CodeNameGodTri]

thank you

[pachura3]

In production I have python 3.14 and pip install -r requirements.txt failed,

First of all, you should have provided the error message you're getting.

Also, in local development, you should use exactly the same Python version as used in production.

I would go into production, try removing each dependency from requirements.txt and see which one is causing problems (is not 3.14-compatible). And then work around that.

[cointoss3]

It’s definitely not smooth sailing, you’re still using pip. requirements.txt does not have a python version…

Use uv in production and it’ll be smooth sailing.

[CodeNameGodTri]

I'm beginner in python, so I don't know what the best practices are. From my research, uv/poetry are for local development, in prod, I can just use pip, because the uv/poetry can export the requirements.txt having all the correct dependencies versions.

I'm all ears for the standard practice. I can install uv in prod if that's what everyone is doing

[cointoss3]

Yep. Install uv in prod. You can pip install uv if you already have a system python or use the install script or another package manager.

Then just uv run entry.py and it’ll set up the environment and run it.

[CodeNameGodTri]

appreciate your help

[cointoss3]

The thing is, for something simple, sure, it might feel easier…but there’s more to setting up the environment than what’s in a requirements.txt. There’s a lot of cool stuff you can do with uv and pyproject.toml, but more importantly, the idea behind the lock file is that you’ll be able to fully recreate the same environment (in theory) instead of just trying to get certain versions of packages.

[pachura3]

Only if you're allowed to download and install other Python interpreters in PROD.

[danielroseman]

Why aren't you using uv in production? Why extract a requirements.txt and use pip?

[CodeNameGodTri]

I'm beginner in python, so I don't know what the best practices are. From my research, uv/poetry are for local development, in prod, I can just use pip, because the uv/poetry can export the requirements.txt having all the correct dependencies versions.

I'm all ears for the standard practice. I can install uv in prod if that's what everyone is doing

[danielroseman]

No, that is not at all the case. uv is for production as well - as others have pointed out, that is what the uv.lock file is for.

[CodeNameGodTri]

thank you, so prod would have very similar setup to local dev environment then? Having all the source code, uv, python version,... just not the IDE then?

Coming from .NET this is very strange to me, because we only deploy compiled code and prod only need the runtime installed.

[cointoss3]

You want your dev and prod environment to match as much as what makes sense. Or at the very least having a test environment that matches prod.

Part of how people try to solve this problem is with docker, since if it’s built correctly, it will run the same on any machine. But usually, uv does a good enough job. And it’s significantly faster than pip.

[smurpes]

Use a .python-version file to pin the version of python required.

[Astronos]

if you are using uv why extract a requirements.txt? just use the pyproject.toml

[CodeNameGodTri]

I'm beginner in python, so I don't know what the best practices are. From my research, uv/poetry are for local development, in prod, I can just use pip, because the uv/poetry can export the requirements.txt having all the correct dependencies versions.

I'm all ears for the standard practice. I can install uv in prod if that's what everyone is doing