[4dregress]

I’ve been a python dev for nearly a decade and never once thought dep management was a problem.

If I’ve ever had to run a “script” in any type of deployed ENV it’s always been done in that ENVs python shell .

So I still don’t see what the fuss is about?

I work on a massive python code base and the only benefit I’ve seen from moving to UV is it has sped up dep installation which has had positive impact on local and CI setup times.

[bboygravity]

How did you tell other people/noobs to run your python code (or how did you run it yourself after 5+ years of not touching older projects)?

[x187463]

run script

"missing x..."

pip install x

run script

"missing y..."

pip install y

> y not found

google y to find package name

pip install ypackage

> conflict with other package

realize I forgot a venv and have contaminated my system python

check pip help output to remember how to uninstall a package

clean up system python

create venv at cwd

start over

...

</end of time>

[jshen]

Python's dependency management has been terrible until very recently compared to nearly every other mainstream language.

[rednafi]

I guess this is why people need to get out of this “Python dev” or “JS dev” mindset and try other languages to see why those coming to Python complain so much about dependency management.

People complain because the experience is less confusing in many other languages. Think Go, Rust, or even JS. All the tooling chaos and virtual environment jujitsu are real deterrents for newcomers. And it’s not just beginners complaining about Python tooling. Industry veterans like Armin Ronacher do that all the time.

uv is a great step in the right direction, but the issue is that as long as the basic tooling isn’t built into the language binary, like Go’s tools or Rust’s Cargo, more tools will pop up and fragment the space even further.

[mmcnl]

Confusing is underselling it. That implies that Python dependency management is working fine, it's just complex. But it's not working fine: there's no such thing as lock files, which makes reproducible installs a gamble and not a given. For small scripts this is probably "okay", but if you're working in a team or want to deploy something on a server, then it's absolutely not fine because you want deterministic builds and that's simply impossible without a decent package manager.

Tools like uv solve the "it works on my machine" problem. And it's also incredibly fast.

[4dregress]

My view is I’m an engineer first and foremost and I use the tools which are best for the task at hand. That also means what’s best for the business in terms of others working on the project, this has meant python with some sort of framework.

People have suggested using other languages that might be faster but the business always choices what’s best for everyone to work with.

[petersellers]

> it’s always been done in that ENVs python shell .

What if you don't have an environment set up? I'm admittedly not a python expert by any means but that's always been a pain point for me. uvx makes that so much easier.

[kinow]

I wrote PHP/JS/Java before Python. Been doing Python for nearly a decade too, and like 4dregress haven't had the need to worry much about dep management. JS and PHP had all sorts of issues, Maven & Gradle are still the ones that gave me less trouble. With Python I found that most issues could be fixed by finding the PEP that implemented what I needed, and by trying to come up with a simple workflow & packaging strategy.

Nowadays I normally use `python venv/bin/<some-executable>`, or `conda run -n <some-env> <some-executable>`, or packaged it in a Singularity container. And even though I hear a lot of good things about uv, given that my job uses public money for research, we try to use open source and standards as much as possible. My understanding is that uv is still backed by a company, and at least when I checked it some time ago (in peps discussions & GH issues) they were no implementing the PEPs that I needed -- even if they did, we would probably still stay with simple pip/setuptools to avoid having to use research budget to update our build if the company ever changed its business model (e.g. what anaconda did some months/year? ago).

Digressing: the Singularity container is useful for research & HPC too, as it creates a single archive, which is faster to load on distributed filesystems like the two I work on (GPFS & LustreFS) instead of loading many small files over network.

[arcanemachiner]

Create a virtual environment:

python3 -m venv venv

Activate the virtual environment:

source venv/bin/activate

Deactivate the virtual environment:

deactivate

[linsomniac]

I've been a python dev for nearly 3 decades and feel that uv is removing a lot of the rough edges around dependency management. So maybe "problem" is the wrong word; I've been able to solve dependency management issues usually without too much trouble, I have also spent a significant amount of time dealing with them. For close to a decade I was managing other peoples Python environments on production systems, and that was a big mess, especially with trying to ensure that they stayed updated and secure.

If you don't see what the fuss is about, I'm happy for you. Sounds like you're living in a fairly isolated environment. But I can assure you that uv is worth a lot of fussing about, it's making a lot of our lives a lot easier.

[mmcnl]

Virtual environments alone are not enough. They don't guarantee deterministic builds. What do you do to ensure that your production environment runs the same code as your local dev environment? How do you solve that problem without dependency managers like uv or poetry?

[bjornasm]

So if you have a big project that is 4 years old and you are going to run it in a new .venv, what do you do?