4 ms·

Yeah, switched to writing python professionally ~4 years ago, and been low key hating the ecosystem. From a java and javascript background, it's mostly been npm

Yeah, switched to writing python professionally ~4 years ago, and been low key hating the ecosystem. From a java and javascript background, it's mostly been npm/mvn install and it "just works". With python, there's always someone being onboarded that can't get it to work. So many small issues. Have to have the correct version per project, then have to get the venv running. And then installing it needs to build stuff because there's no wheel, so need to set up a complete c++ and rust toolchain etc., just to pull a small project and run it. uv doesn't solve all this, but it's reduced the amount of ways things can go wrong by a lot. And it being fast means that the feedback-loop is much quicker.

gunalx 2y ago
I cannot share the same experiences. mvn is a buggy mess, randomly forgetting dependencies, and constantly needing a full clean to not die on itself. npm and the entire js ecosystem feels so immature with constant breaking changes, and circular dependency hell, when trying to uppgrade stuff.
- Etheryte 2y ago
  That's an issue with the packages themselves though, not with package management as a whole. You and the comment above you are talking about different things. While there's plenty of pain to be had with npm, if you have a project that used to work years ago, you can generally just clone, install and be done, even if on older versions. On Python this used to mean a lot of hurt, often even if it was a fresh project that you just wanted to share with a colleague.
  - TeMPOraL 2y ago
    For value of "years" greater than 1? Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.
    - wfme 2y ago
      Projects breaking so frequently on npm and node is simply not the case unless you are trying upgrade an old project, one dependency per day…
    - Etheryte 2y ago
      This argument makes no sense. Your dependencies don't change unless you change them, npm doesn't magically update things underneath you. Things can break when you try to update one thing or another, yes, but if you just take an old project and try and run it, it will work.
      - nicoburns 2y ago
        > npm doesn't magically update things underneath you It used to prior to npm 5 when lockfiles were introduced (yarn introduced lockfiles earlier).
      - TeMPOraL 2y ago
        Assuming the downloads still exist? Does NPM cache all versions it ever distributed? That's always one major thing I saw breaking old builds: old binaries stop being hosted, forcing you to rebuild them from old source, which no longer builds under current toolchains - making you either downgrade the toolchain that itself may be tricky to set up, or upgrade the library, which starts a cascade of dependency upgrades. It's not like Node projects are distributed with their deps vendored; there's too much stuff in node_modules.
        lucianbr 2y ago
        You're using a different, not hosted anymore package, three times a week? That's somewhere between very unusual and downright absurd. Yes you can find edge cases with problems. Using this as an argument for "breaks 3 times per week" does not hold.
        TeMPOraL 2y ago
        No, I was using this as an argument for why I don't expect Node projects older than a year or two to be buildable without significant hassle. (Also note that outside the web/mobile space, projects that weren't updated in a year are still young, not old. "Old" is more like 5+ years.) The two things are related. If your typical project has a dependency DAG of 1000+ projects, a bug or CVE fix somewhere will typically cause a cascade of potentially breaking updates to play out over multiple days, before everything stabilizes. This creates pressure for everyone to always stay on the bleeding edge; with a version churn like this, there's only so many old (in the calendar sense) package dists that people are willing to cache. This used to be a common experience some years back. Like many others, I gave up on the ecosystem because of the extreme fragility of it. If it's not like that anymore, I'd love to be corrected.
- PaulHoule 2y ago
  I've seen mvn projects that spin like a top and others that were a disaster. I think it's little recognized that there is a scaling limit for snapshots. If you have 20 people developing 20 projects and they are co-located in the same room with the server builds work 50-80% of the time and people think it's fine. If you're the one guy who is remote and has a slow connection, builds work 0% of the time. The problem is that at slightly different times you get slightly different snapshots that aren't compatible with each other -- it's a scaling problem because if you add enough developers and enough projects it will eventually get you. I've worked at other places when the mvn clean was necessary every time; other developers thought this shouldn't be necessary and I was a doofus except I was able to make consistent progress like a ratchet on the project and get it done and they weren't. Where I am now mvn is just fine, whenever it screws up there's a rational explanation and we're doing it wrong.
- matsemann 2y ago
  I'm not saying mvn or npm is perfect. But the issues they have are consistent. My coworker and I would either have the same issues or not any issues. But with python it's probably more ways of running the project in the team than there are people, all with small tweaks to get it working on their system.
notpushkin 2y ago
Python has been mostly working okay for me since I switched to Poetry. (“Mostly” because I think I’ve run into some weird issue once but I’ve tried to recall what it was and I just can’t.) uv felt a bit immature at the time, but sounds like it’s way better now. I really want to try it out... but Poetry just works, so I don’t really have an incentive to switch just yet. (Though I’ve switched from FlakeHeaven or something to Ruff and the difference was heaven and hell! Pun in’tended.)
- ThibWeb 2y ago
  A lot of Wagtail usage is with Poetry. Tends to be projects with 30-50 dependencies. It "just works" but we see a lot of people struggle with common tasks ("how do I upgrade this package"), and complain about how slow it is. I don’t have big insights outside of Wagtail users but I don’t think it’s too different.
  - raihansaputra 2y ago
    n=1 but i've tried "manual" .venv, conda/miniconda, pipenv, poetry, and finally now at uv. uv is great. poetry feels like it's focused on people who are publishing packages. uv is great to use for personal dev, spinning up/down lots of venv, speedy, and uvx/uv script is very convenient compared to having all my sandbox project in one poetry env.

gunalx 2y ago

I cannot share the same experiences. mvn is a buggy mess, randomly forgetting dependencies, and constantly needing a full clean to not die on itself. npm and the entire js ecosystem feels so immature with constant breaking changes, and circular dependency hell, when trying to uppgrade stuff.

Etheryte 2y ago
That's an issue with the packages themselves though, not with package management as a whole. You and the comment above you are talking about different things. While there's plenty of pain to be had with npm, if you have a project that used to work years ago, you can generally just clone, install and be done, even if on older versions. On Python this used to mean a lot of hurt, often even if it was a fresh project that you just wanted to share with a colleague.
- TeMPOraL 2y ago
  For value of "years" greater than 1? Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.
  - wfme 2y ago
    Projects breaking so frequently on npm and node is simply not the case unless you are trying upgrade an old project, one dependency per day…
  - Etheryte 2y ago
    This argument makes no sense. Your dependencies don't change unless you change them, npm doesn't magically update things underneath you. Things can break when you try to update one thing or another, yes, but if you just take an old project and try and run it, it will work.
    - nicoburns 2y ago
      > npm doesn't magically update things underneath you It used to prior to npm 5 when lockfiles were introduced (yarn introduced lockfiles earlier).
    - TeMPOraL 2y ago
      Assuming the downloads still exist? Does NPM cache all versions it ever distributed? That's always one major thing I saw breaking old builds: old binaries stop being hosted, forcing you to rebuild them from old source, which no longer builds under current toolchains - making you either downgrade the toolchain that itself may be tricky to set up, or upgrade the library, which starts a cascade of dependency upgrades. It's not like Node projects are distributed with their deps vendored; there's too much stuff in node_modules.
      - lucianbr 2y ago
        You're using a different, not hosted anymore package, three times a week? That's somewhere between very unusual and downright absurd. Yes you can find edge cases with problems. Using this as an argument for "breaks 3 times per week" does not hold.
        TeMPOraL 2y ago
        No, I was using this as an argument for why I don't expect Node projects older than a year or two to be buildable without significant hassle. (Also note that outside the web/mobile space, projects that weren't updated in a year are still young, not old. "Old" is more like 5+ years.) The two things are related. If your typical project has a dependency DAG of 1000+ projects, a bug or CVE fix somewhere will typically cause a cascade of potentially breaking updates to play out over multiple days, before everything stabilizes. This creates pressure for everyone to always stay on the bleeding edge; with a version churn like this, there's only so many old (in the calendar sense) package dists that people are willing to cache. This used to be a common experience some years back. Like many others, I gave up on the ecosystem because of the extreme fragility of it. If it's not like that anymore, I'd love to be corrected.
PaulHoule 2y ago
I've seen mvn projects that spin like a top and others that were a disaster. I think it's little recognized that there is a scaling limit for snapshots. If you have 20 people developing 20 projects and they are co-located in the same room with the server builds work 50-80% of the time and people think it's fine. If you're the one guy who is remote and has a slow connection, builds work 0% of the time. The problem is that at slightly different times you get slightly different snapshots that aren't compatible with each other -- it's a scaling problem because if you add enough developers and enough projects it will eventually get you. I've worked at other places when the mvn clean was necessary every time; other developers thought this shouldn't be necessary and I was a doofus except I was able to make consistent progress like a ratchet on the project and get it done and they weren't. Where I am now mvn is just fine, whenever it screws up there's a rational explanation and we're doing it wrong.
matsemann 2y ago
I'm not saying mvn or npm is perfect. But the issues they have are consistent. My coworker and I would either have the same issues or not any issues. But with python it's probably more ways of running the project in the team than there are people, all with small tweaks to get it working on their system.

notpushkin 2y ago

Python has been mostly working okay for me since I switched to Poetry. (“Mostly” because I think I’ve run into some weird issue once but I’ve tried to recall what it was and I just can’t.) uv felt a bit immature at the time, but sounds like it’s way better now. I really want to try it out... but Poetry just works, so I don’t really have an incentive to switch just yet. (Though I’ve switched from FlakeHeaven or something to Ruff and the difference was heaven and hell! Pun in’tended.)

ThibWeb 2y ago
A lot of Wagtail usage is with Poetry. Tends to be projects with 30-50 dependencies. It "just works" but we see a lot of people struggle with common tasks ("how do I upgrade this package"), and complain about how slow it is. I don’t have big insights outside of Wagtail users but I don’t think it’s too different.
- raihansaputra 2y ago
  n=1 but i've tried "manual" .venv, conda/miniconda, pipenv, poetry, and finally now at uv. uv is great. poetry feels like it's focused on people who are publishing packages. uv is great to use for personal dev, spinning up/down lots of venv, speedy, and uvx/uv script is very convenient compared to having all my sandbox project in one poetry env.