4 ms·

> lack of robust python support There is no such thing. Tell me, which combination of the 15+ virtual environments, dependency management and Python version ma

> lack of robust python support There is no such thing. Tell me, which combination of the 15+ virtual environments, dependency management and Python version managers would you use? And how would you prevent "project collision" (where one Python project bumps into another one and one just stops working)? Example: SSL library differences across projects is a notorious culprit. Python is garbage and I don't understand why people put up with this crap unless you seriously only run ONE SINGLE Python project at a time and do not care what else silently breaks. Having to run every Python app in its own Docker image (which is the only real solution to this, if you don't want to learn Nix, which you really should, because it is better thanks to determinism... but entails its own set of issues) is not a reasonable compromise. Was so glad when the Elixir guys came out with this recently, to at least be able to use Python, but in a very controlled, not-insane way: https://dashbit.co/blog/running-python-in-elixir-its-fine https://dashbit.co/blog/running-python-in-elixir-its-fine

simonw 2y ago
uv (Not saying Apple should bundle that, but it's the best current answer to running many different Python projects without using something like Docker)
mapcars 2y ago
> at least be able to use Python, but in a very controlled, not-insane way Thats funny, about 10 years ago I started my career in a startup that had Python business logic running under Erlang (via custom connector) which handled supervision and task distribution, and it looked insane for me at the time. Even today I think it can be useful but is very hard to maintain, and containers are a good enough way to handle python.
- pmarreck 2y ago
  > containers are a good enough way to handle python I disagree. My take on that is that they are an ugly enough way to handle Python. And, among other problems, don't permit you to easily mess with the code (one of many reasons why this is ugly). Need access to something stateful from the container app? That's another PITA.
kstrauser 2y ago
Virtualenv’s been a thing for many years, it’s built into Python, and it solves all that without adding additional tooling. And if you’re genuinely asking, everything’s converging toward uv. If you pick only one, use that and be done with it.
- hedora 2y ago
  I’ve been using virtualenv for a decade, and we use uv at work. Neither fixed anything. They just make it slightly less painful to deal with python scripts’ constant bitrot. They also make python uniquely difficult to dockerize.
  - kstrauser 2y ago
    That's so completely, diametrically opposite of my experience with both that I can't help but wonder how it ended up there. > They also make python uniquely difficult to dockerize. RUN pip install uv && uv sync Tada, done. No, seriously. That's the whole invocation.
    - pmarreck 2y ago
      So you've never encountered a stale python project that used to work and had difficulties getting it up and running again? Do you actually try new Python projects out with git-clone, or do you just use the same 3 Python projects for years at a time (all regularly)? That might explain the difference in experiences
whimsicalism 2y ago
these are solved problems now, check back in. uv is now the standard
- pmarreck 2y ago
  Cool. To paraphrase an old XKCD (https://xkcd.com/927/ https://xkcd.com/927/), now there are 16 standards!
  - whimsicalism 2y ago
    uv is actually winning primacy nevermind that they’re all interoperable
tomn 2y ago
This is incoherent to me. Your complaints are about packaging, but the elixir wrapper doesn't deal with that in any way -- it just wraps UV, which you could use without elixir. What am I missing? Also, typically when people say things like > Tell me, which combination of the 15+ virtual environments, dependency management and Python version managers It means they have been trapped in a cycle of thinking "just one more tool will surely solve my problem", instead of realising that the tools _are_ the problem, and if you just use the official methods (virtualenv and pip from a stock python install), things mostly just work.
- kstrauser 2y ago
  I agree. Python certainly had its speedbumps, but it's utterly manageable today and has been for years and years. It seems like people get hung up on there not being 1 official way to do things, but I think that's been great, too: the competition gave us nice things like Poetry and UV. The odds are slim that a Rust tool would've been accepted as the official Python.org-supplied system, but now we have it. There are reasons to want something more featureful than plain pip. Even without them, pip+virtualenv has been completely usable for, what, 15 years now?
  - pmarreck 2y ago
    I've seen issues with pip + virtualenv (ssl lib issues, IIRC). I've always used those at minimum and have still run into problems. (I like to download random projects to try them out.) I've also seen issues with python projects silently becoming stale and not working, or python projects walking over other python projects because pip + virtualenv does NOT encompass all Python deps to the metal. This also doesn't mean you can have 2 commandline Python apps available in the same commandline environment, because PATH would have to prefer one or the other at some point. Here's a question- If you don't touch a project in 1 year, do you expect it to still work, or not? If your answer is the latter, then we simply won't see eye-to-eye on this.
- pmarreck 2y ago
  > mostly just work that's not good enough. If I'm in the business of writing Python code, I (ideally) don't want to _also_ be in the business of working around Python design deficiencies. Either solve the problem definitively, or do not try to solve the problem at all, because the middle road just leads to endless headaches for people WHILE ALSO disincentivizing a better solution. Node has better dependency management than Python- And that's really saying something.

simonw 2y ago

uv (Not saying Apple should bundle that, but it's the best current answer to running many different Python projects without using something like Docker)

mapcars 2y ago

> at least be able to use Python, but in a very controlled, not-insane way Thats funny, about 10 years ago I started my career in a startup that had Python business logic running under Erlang (via custom connector) which handled supervision and task distribution, and it looked insane for me at the time. Even today I think it can be useful but is very hard to maintain, and containers are a good enough way to handle python.

pmarreck 2y ago
> containers are a good enough way to handle python I disagree. My take on that is that they are an ugly enough way to handle Python. And, among other problems, don't permit you to easily mess with the code (one of many reasons why this is ugly). Need access to something stateful from the container app? That's another PITA.

kstrauser 2y ago

Virtualenv’s been a thing for many years, it’s built into Python, and it solves all that without adding additional tooling. And if you’re genuinely asking, everything’s converging toward uv. If you pick only one, use that and be done with it.

hedora 2y ago
I’ve been using virtualenv for a decade, and we use uv at work. Neither fixed anything. They just make it slightly less painful to deal with python scripts’ constant bitrot. They also make python uniquely difficult to dockerize.
- kstrauser 2y ago
  That's so completely, diametrically opposite of my experience with both that I can't help but wonder how it ended up there. > They also make python uniquely difficult to dockerize. RUN pip install uv && uv sync Tada, done. No, seriously. That's the whole invocation.
  - pmarreck 2y ago
    So you've never encountered a stale python project that used to work and had difficulties getting it up and running again? Do you actually try new Python projects out with git-clone, or do you just use the same 3 Python projects for years at a time (all regularly)? That might explain the difference in experiences

whimsicalism 2y ago

these are solved problems now, check back in. uv is now the standard

pmarreck 2y ago
Cool. To paraphrase an old XKCD (https://xkcd.com/927/ https://xkcd.com/927/), now there are 16 standards!
- whimsicalism 2y ago
  uv is actually winning primacy nevermind that they’re all interoperable

tomn 2y ago

This is incoherent to me. Your complaints are about packaging, but the elixir wrapper doesn't deal with that in any way -- it just wraps UV, which you could use without elixir. What am I missing? Also, typically when people say things like > Tell me, which combination of the 15+ virtual environments, dependency management and Python version managers It means they have been trapped in a cycle of thinking "just one more tool will surely solve my problem", instead of realising that the tools _are_ the problem, and if you just use the official methods (virtualenv and pip from a stock python install), things mostly just work.

kstrauser 2y ago
I agree. Python certainly had its speedbumps, but it's utterly manageable today and has been for years and years. It seems like people get hung up on there not being 1 official way to do things, but I think that's been great, too: the competition gave us nice things like Poetry and UV. The odds are slim that a Rust tool would've been accepted as the official Python.org-supplied system, but now we have it. There are reasons to want something more featureful than plain pip. Even without them, pip+virtualenv has been completely usable for, what, 15 years now?
- pmarreck 2y ago
  I've seen issues with pip + virtualenv (ssl lib issues, IIRC). I've always used those at minimum and have still run into problems. (I like to download random projects to try them out.) I've also seen issues with python projects silently becoming stale and not working, or python projects walking over other python projects because pip + virtualenv does NOT encompass all Python deps to the metal. This also doesn't mean you can have 2 commandline Python apps available in the same commandline environment, because PATH would have to prefer one or the other at some point. Here's a question- If you don't touch a project in 1 year, do you expect it to still work, or not? If your answer is the latter, then we simply won't see eye-to-eye on this.
pmarreck 2y ago
> mostly just work that's not good enough. If I'm in the business of writing Python code, I (ideally) don't want to _also_ be in the business of working around Python design deficiencies. Either solve the problem definitively, or do not try to solve the problem at all, because the middle road just leads to endless headaches for people WHILE ALSO disincentivizing a better solution. Node has better dependency management than Python- And that's really saying something.