Question: Will it also replace pipenv?

[TheRealBecks]

Have you already heard about pipenv? I saw that you talking about replacing several package managers and virtualization managers, but I didn't see you mentioning pipenv.

Key benefits of using pipenv:

• replaces pip and venv
• No shitty requirements.txt, but a structured Pipfile
• The production or development installation from Pipfile will result in a Pipfile.lock that uses hashes to strengthen the security, but also allows to install binary-equal versions on several platform, so you development install can be equally to the production setup on a server
• Integrated into VS Code, so the virtual environment can be used directly

Especially using a .lock with hashes file instead of the requirements.txt is a killer feature. I would love to see something equal at uv.

[moaddib666]

Upvote this question, as pip has security concerns when we need to work with several registries private and public ones, and it's great to have lock files so that on CI we don't need to make any additional resolution at all.

[hauntsaninja]

uv pip compile supports pip-compile's --generate-hashes flag if you want a lock file with hashes. I believe uv aims on introducing a higher level UI in the future, but the low level commands are there.

[thomasleveil]

It would be nice to be able to just type :

uv pip compile Pipfile --generate-hashes -o requirements.txt # Read a Pipenv file.

In the meantime, a workaround is :

pipenv requirements > requirements.in
uv pip compile requirements.in --generate-hashes -o requirements.txt

[astrojuanlu]

It is my understanding that the community has been trying to standardise a lockfile for years:

• Take 1 https://peps.python.org/pep-0650/ withdrawn
• Take 2 https://peps.python.org/pep-0665/ rejected

And to the best of my knowledge, efforts continue to provide such a standard.

It was comforting to see the uv devs being so open and receptive to community feedback already and I hope they take a sensible approach and carefully avoid blessing locking formats that are far from being "standard".

[helderco]

@thomasleveil, you can also pass stdin:

pipenv requirements | uv pip compile --generate-hashes -o requirements.txt -

@astrojuanlu, there's a Take 3 (discussion phase, before PEP), continuing from the mousebender project 🙂

[vlad-ivanov-name]

take a sensible approach and carefully avoid blessing locking formats that are far from being "standard".

Just because something is an "official" standard doesn't necessarily mean it's good or well designed -- I think Python of all ecosystems is an example of that. If Python can't settle on a lockfile standard for several more years, I don't see why uv should be held back and not implement either its own format or one of the proposals.

[zanieb]

We're building a lock file; see #3347

[datalifenyc]

@TheRealBecks Have you made the switch to uv? As a pipenv user, is there anything I should know about making the transition to uv?

[TheRealBecks]

@datalifenyc Yes, absolutely! 😀 I already migrated the first production repositiries at work and the local development instances with Docker container and the production setup is way easier and even faster to set up!

Here's an example pyproject.toml:

[project]
name = "your-project-name"
description = "Your Project Description"
readme = "README.md"
version = "1.0.0"
requires-python = ">=3.12.5,<3.13"
dependencies = [
  "ansible==9.10.*",
  "ansible-core==2.16.*",
  "ansible-pylibssh",
  "hvac",
  "jmespath",
  "netaddr",
  "paramiko",
]

[project.optional-dependencies]
dev = [
  "ansible-lint",
  "icecream",
  "ruff",
]

[tool.ruff]
line-length = 120
target-version = "py312"
# Allow autofix for all enabled rules (when `--fix`) is provided.
lint.fixable = ["ALL"]
lint.select = ["ALL"]
lint.ignore = ["COM812", "D203", "D212", "D415", "FIX002", "TD003"]

[tool.ruff.lint.per-file-ignores]
"__init__.py" = ["D104", "F401"]

I use requires-python = ">=3.12.5,<3.13" as our project relies on python 3.12 (and nothing else!) with at least Python 3.12.5 or newer bug fix release.

I also deactivated the Windows build as we don't use Windows and ansible-lint is also not available anymore on that platform. Optionally put that at the end of the pyproject.toml:

[tool.uv]
# Disable Windows as some packages are not compiled for that system
environments = ["platform_system != 'Windows'"]

With uv sync --extra dev you can install and create an initial uv.lock file on your local system. With uv pip freeze you can check which package versions have been chossen for all platform (Linux, MacOS). Add pyproject.toml and uv.lock to you git repository.

You can use the 'old' way of activating an environment with source .venv/bin/activate, but I'm _not doing that anymore, because uv run or uvx are way easier to use, like:

uv run my_python_script.py

You can also run tools like FastAPI (see this documentation) with that command:

uv run fastapi dev

Or put everything into Docker.

While writing this comment it came into my mind to create an example project with uv and ansbible, so here's somethign you can copy from:

TheRealBecks/uv-ansible-example

I hope this will help you and also other users (including myself 😀)

[datalifenyc]

@TheRealBecks Thank you for the detailed project setup and ansible repo! This will definitely simplify my transition, especially with the references to fastapi and docker.

[cclauss]

https://pypi.org/project/pipenv-uv-migrate