4 ms·

This hasn't really been true for a while now. `uv` has radically improved the experience.

cedws 1y ago
There’s still 20 years of projects using everything that became before uv. They didn’t upgrade the moment uv came into existence. Data science-land still uses other rubbish too.
- zimpenfish 1y ago
  > They didn’t upgrade the moment uv came into existence. There's also projects that can't use `uv` because it doesn't like their current `requirements.txt`[0] and I have no bandwidth to try and figure out how to work around it. [0] We have an install from `git+https` in there and it objects strongly for some reason. Internet searches have not revealed anything helpful.
  - bootsmann 1y ago
    Unrelated to uv but the problem with having a git ref in requirements.txt is that pip will treat it as a fixed version so it will strictly narrow the other dependencies it can resolve, which gets exceptionally difficult to reason about once that packages also loads a package from another git ref. Throwing everything into codeartifact (or equivalent on other clouds) is better longterm.
  - zanie 1y ago
    If you open even a brief issue and tag me @zanieb I'm happy to take a look!
    - zimpenfish 1y ago
      Ta, will give that a go when I've got some free time.
bborud 1y ago
For the last 20 years that has been the mantra. Some X "solves" all the problems. Except it doesn't. It just creates another X that is popular for a while, and doesn't somehow retroactively "fix" all the chaotic projects that are a nightmare to install and upgrade. Yes, I understand people like Python. Yes, I understand the LLM bros love it. But in a real production environment, for real applications, you still want to avoid it because it isn't particularly easy to create robust systems for industrial use. You may survive if you can contain the madness in a datacenter somewhere and have people babysit it.
- bodge5000 1y ago
  I can get that Pythons not for everyone, it certainly has its flaws and maybe uv is just another transient solution which will come and go and others have. I might disagree, but I can accept that. What I can't accept is the idea that it should be avoided for real production environments, which is frankly a bit ridiculous considering all the real applications and real production environments running on Python.
- bbkane 1y ago
  I think that's true until it isn't, and people are really rallying around uv. Here's to hoping it manages to actually solve the Python packagig issue (and lots of people are saying it already has for their use cases)!
  - bborud 1y ago
    Solving it at least involves the Python maintainers making a choice, integrating it into the Python binary and sticking to it. At least. But that requires possibly annoying some people until a) whatever solution becomes mature and b) people get over it.
- turtlebits 1y ago
  I've ignored the trends and just used the bog standard requirements.txt with pip and a virtualenv and have had no problems in the past 10+ years. Either way, you always want to catch production deploys if something breaks.

There’s still 20 years of projects using everything that became before uv. They didn’t upgrade the moment uv came into existence. Data science-land still uses other rubbish too.

zimpenfish 1y ago
> They didn’t upgrade the moment uv came into existence. There's also projects that can't use `uv` because it doesn't like their current `requirements.txt`[0] and I have no bandwidth to try and figure out how to work around it. [0] We have an install from `git+https` in there and it objects strongly for some reason. Internet searches have not revealed anything helpful.
- bootsmann 1y ago
  Unrelated to uv but the problem with having a git ref in requirements.txt is that pip will treat it as a fixed version so it will strictly narrow the other dependencies it can resolve, which gets exceptionally difficult to reason about once that packages also loads a package from another git ref. Throwing everything into codeartifact (or equivalent on other clouds) is better longterm.
- zanie 1y ago
  If you open even a brief issue and tag me @zanieb I'm happy to take a look!
  - zimpenfish 1y ago
    Ta, will give that a go when I've got some free time.

bborud 1y ago

For the last 20 years that has been the mantra. Some X "solves" all the problems. Except it doesn't. It just creates another X that is popular for a while, and doesn't somehow retroactively "fix" all the chaotic projects that are a nightmare to install and upgrade. Yes, I understand people like Python. Yes, I understand the LLM bros love it. But in a real production environment, for real applications, you still want to avoid it because it isn't particularly easy to create robust systems for industrial use. You may survive if you can contain the madness in a datacenter somewhere and have people babysit it.

bodge5000 1y ago
I can get that Pythons not for everyone, it certainly has its flaws and maybe uv is just another transient solution which will come and go and others have. I might disagree, but I can accept that. What I can't accept is the idea that it should be avoided for real production environments, which is frankly a bit ridiculous considering all the real applications and real production environments running on Python.
bbkane 1y ago
I think that's true until it isn't, and people are really rallying around uv. Here's to hoping it manages to actually solve the Python packagig issue (and lots of people are saying it already has for their use cases)!
- bborud 1y ago
  Solving it at least involves the Python maintainers making a choice, integrating it into the Python binary and sticking to it. At least. But that requires possibly annoying some people until a) whatever solution becomes mature and b) people get over it.
turtlebits 1y ago
I've ignored the trends and just used the bog standard requirements.txt with pip and a virtualenv and have had no problems in the past 10+ years. Either way, you always want to catch production deploys if something breaks.