5 ms·

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

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.

petersellers 1y ago
> 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 1y ago
  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 1y ago
  Create a virtual environment: python3 -m venv venv Activate the virtual environment: source venv/bin/activate Deactivate the virtual environment: deactivate
  - petersellers 1y ago
    Or: `uvx ruff` Which one is easier to run, especially for someone who doesn't use python everyday?
    - arcanemachiner 1y ago
      The one they definitely won't have to re-learn in a few years.
      - petersellers 1y ago
        It's still easier if you use virtual environments so infrequently that you have to look up how to do it every time.
      - fastasucan 1y ago
        Oh, I am fine re-learning an equivalent of `uvx ruff` every few years, thats not too bad.
jshen 1y ago
Python's dependency management has been terrible until very recently compared to nearly every other mainstream language.
bboygravity 1y ago
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 1y ago
  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>
  - SAI_Peregrinus 1y ago
    Thankfully some newer systems will error by default if you try to mess with them via pip instead of your system's package manager. Easy to override if you want to, and saves a lot of effort fixing accidental screw ups.
  - psunavy03 1y ago
    >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 This hits disturbingly close to home.
    - whattheheckheck 1y ago
      This is like seeing someone complain they have to turn their computer on to do work
rednafi 1y ago
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 1y ago
  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.
  - rednafi 1y ago
    There is a lock file now. https://packaging.python.org/en/latest/specifications/pylock-toml/#pylock-toml-spec https://packaging.python.org/en/latest/specifications/pylock... Issue is since there are no standardized build tool (pip, uv both are third party), there are a zillion ways of generating this lockfile unlike go.mod or cargo.toml. So it doesn't work in many scenarios and it's confusing as hell.
- 4dregress 1y ago
  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.
mmcnl 1y ago
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?
linsomniac 1y ago
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.
bjornasm 1y ago
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?

petersellers 1y ago

> 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 1y ago
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 1y ago
Create a virtual environment: python3 -m venv venv Activate the virtual environment: source venv/bin/activate Deactivate the virtual environment: deactivate
- petersellers 1y ago
  Or: `uvx ruff` Which one is easier to run, especially for someone who doesn't use python everyday?
  - arcanemachiner 1y ago
    The one they definitely won't have to re-learn in a few years.
    - petersellers 1y ago
      It's still easier if you use virtual environments so infrequently that you have to look up how to do it every time.
    - fastasucan 1y ago
      Oh, I am fine re-learning an equivalent of `uvx ruff` every few years, thats not too bad.

jshen 1y ago

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

bboygravity 1y ago

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 1y ago
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>
- SAI_Peregrinus 1y ago
  Thankfully some newer systems will error by default if you try to mess with them via pip instead of your system's package manager. Easy to override if you want to, and saves a lot of effort fixing accidental screw ups.
- psunavy03 1y ago
  >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 This hits disturbingly close to home.
  - whattheheckheck 1y ago
    This is like seeing someone complain they have to turn their computer on to do work

rednafi 1y ago

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 1y ago
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.
- rednafi 1y ago
  There is a lock file now. https://packaging.python.org/en/latest/specifications/pylock-toml/#pylock-toml-spec https://packaging.python.org/en/latest/specifications/pylock... Issue is since there are no standardized build tool (pip, uv both are third party), there are a zillion ways of generating this lockfile unlike go.mod or cargo.toml. So it doesn't work in many scenarios and it's confusing as hell.
4dregress 1y ago
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.

mmcnl 1y ago

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?

linsomniac 1y ago

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.

bjornasm 1y ago

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?