6 ms·

Please consider consolidating python dependency management instead of fragmenting it: https://docs.astral.sh/uv/pip/compile/ https://docs.astral.sh/uv/pip/comp

Please consider consolidating python dependency management instead of fragmenting it: https://docs.astral.sh/uv/pip/compile/ https://docs.astral.sh/uv/pip/compile/ In other words, bring the thinking here. Whether it's new thinking, or decade old thinking, it's well time to converge. We've had decades of trying it like Heinz catsup varieties. Worth trying more wood behind fewer arrows.

Spivak 2y ago
You're just picking a winner like every other Python dependency project. If it's not in a PEP do whatever the hell you want. Good ideas will get turned into future PEPs for tooling to standardize on. uv itself has two separate locking formats.
- halfcat 2y ago
  > If it's not in a PEP Yes exactly https://xkcd.com/927/ https://xkcd.com/927/
imjonse 2y ago
One can start non-distruptively with uv by only using it as a pipx replacement at first ( uv tool). Nice and fast.
Der_Einzige 2y ago
Please consider consolidating python dependency management instead of fragmenting it: https://github.com/mamba-org/mamba https://github.com/mamba-org/mamba In other words, bring the thinking here. Whether it's new thinking, or decade old thinking, it's well time to converge. We've had decades of trying it like Heinz catsup varieties. Worth trying more wood behind fewer arrows.
- kstrauser 2y ago
  While I don't know which (if any) Python package manager will "win", I'm confident it won't be Conda or similar. I hope and pray not, anyway.
  - matrss 2y ago
    Yes, the entire workflow of conda/mamba is a liability. Having environments detached from directories encourages bad practices (reusing environments for unrelated things, installing everything into the same environment and getting very broken dependency resolutions, that stuff) and it doesn't even have a lock file format, so environments can't be saved short of dumping its entire directory. Iff it must be the conda ecosystem, pixi (https://pixi.sh/latest/ https://pixi.sh/latest/) is a much better pick. But conda-style packages (or anything with install time dependency resolution really) also have the issue of being completely untestable. That makes them unsuitable at least for user-facing package management, if you care about your packages not randomly breaking without warning. I'd rather see every language converge on a single package manager that implements functional package management, i.e. guix or nix. One can dream...
    - skeledrew 2y ago
      I've been using a conda+poetry flow for years and it's worked very well. Particularly because envs aren't tied to projects. I tried pixi for a few days in a project months ago and it was just breakage and untenable limitations all around. I prefer the freedom of using per project envs when I want, and shared envs other times.
      - matrss 2y ago
        What are you using each of them for in that workflow? I've found that there really only are two kinds of packages I want to install: those I want globally (e.g. CLI tools like git, git-annex, DataLad, whatever shell enhancing you want, etc.) and project-specific dependencies (anything required to get going with it on a freshly installed system with the smallest amount of assumptions possible). The former is sufficiently addressed by `pixi global` and other package managers, the latter by pixi projects. Notably, conda environments are a bad fit for both (not global, not really updatable, not automatically tied to a project, not rebuildable due to missing lock files, ...).
        thejevans 2y ago
- notatallshaw 2y ago
  > Please consider consolidating python dependency management instead of fragmenting it: https://github.com/mamba-org/mamba https://github.com/mamba-org/mamba Mamba doesn't even interact with the official python packing ecosystem... It is purely a conda replacement and conda packaging is not Python packaging (it's a more fundamental fragmentation than choosing a particular tool). So weird choice to not fragment Python dependency management. If you depend on both conda and standard Python packaging (e.g. PyPI.org) you can use Pixi: https://github.com/prefix-dev/pixi?tab=readme-ov-file#pixi-package-management-made-easy https://github.com/prefix-dev/pixi?tab=readme-ov-file#pixi-p.... Pixi attempts to bridge the conda world and the Python package world, so it's possible to rely more deeply on standards based packaging but still use conda tooling when you need it.
jonathrg 2y ago
How is uv, another flavor-of-the-month Python packaging tool, not contributing to fragmentation?
- danglymarsh 2y ago
  [flagged]
  - alephxyz 2y ago
    Source? Never heard of it until today
    - colechristensen 2y ago
      I looked into uv a while back and it indeed was considerably faster than pip, but the folks who created it seem like they're trying a business around python tooling and are in the early stages. There is a risk of a rug pull of some kind down the road when they decide they want to make money and that to me was too much of a risk at present. https://astral.sh/about https://astral.sh/about
    - danglymarsh 2y ago
      [flagged]
      - alephxyz 2y ago
        I'm not gonna dig up someone's history to figure out what you mean. If you're going to make a throwaway account to insult someone at least be explicit about your accusations.
- the_mitsuhiko 2y ago
  uv unlike all other options has the best shot at becoming the one.
  - kstrauser 2y ago
whalesalad 2y ago
This is not fragmenting it. The requirements.txt file has been a steady and well used API for well over a decade. This tool just helps you produce one for a project that is missing one.
ris 2y ago
How about you stop trying to create package managers for every single language/ecosystem in existence and instead converge on trying to solve the whole problem once and for all with Nix.
- verandaguy 2y ago
  Asking honestly since I've seen Nix and NixOS show up on the front page here a bunch over the years, but never used it: my impression of it is that it fills the same kind of niche as the Zig or Nim languages: conceptually pretty cool, but not widely adopted outside of a dedicated core user group. Is this really the case for Nix, or is it actually widely adopted, and this adoption is underreported? If it's not actually widely adopted, what do you think are the biggest obstacles in Nix's way?
jghn 2y ago
> Please consider consolidating python dependency management instead of fragmenting it You realize that this project predates uv by roughly a decade, right?
- Terretta 2y ago
  [flagged]
  - chaps 2y ago
    Can you expand on what you mean, exactly?
    - throwaway314155 2y ago
      They thought they had a better advertising chance for `uv` than they actually did. As far as I can tell, `uv` is a replacement for `pip`. But the project linked by OP doesn't actually replace `pip`, but rather a small subset of functionality in `pip` - `pip freeze`. Unless `uv` has some sort of import scanning functionality, the suggestion to use `uv` instead doesn't really make any sense.
      - Terretta 2y ago
        On the contrary, read this about `uv` by the author of `rye`: https://lucumr.pocoo.org/2024/8/21/harvest-season/ https://lucumr.pocoo.org/2024/8/21/harvest-season/ Domination is a goal because it means that most investment will go into one stack. I can only re-iterate my wish and desire that Rye (and with it a lot of other tools in the space) should cease to exist once the dominating tool has been established. For me uv is poised to be that tool. It's not quite there today yet for all cases, but it will be in no time, and now is the moment to step up as a community and start to start to rally around it. Yes, I linked to an obscure feature uv supports. It's already a rather lot more.
        throwaway314155 2y ago

Spivak 2y ago

You're just picking a winner like every other Python dependency project. If it's not in a PEP do whatever the hell you want. Good ideas will get turned into future PEPs for tooling to standardize on. uv itself has two separate locking formats.

halfcat 2y ago
> If it's not in a PEP Yes exactly https://xkcd.com/927/ https://xkcd.com/927/

imjonse 2y ago

One can start non-distruptively with uv by only using it as a pipx replacement at first ( uv tool). Nice and fast.

Der_Einzige 2y ago

Please consider consolidating python dependency management instead of fragmenting it: https://github.com/mamba-org/mamba https://github.com/mamba-org/mamba In other words, bring the thinking here. Whether it's new thinking, or decade old thinking, it's well time to converge. We've had decades of trying it like Heinz catsup varieties. Worth trying more wood behind fewer arrows.

kstrauser 2y ago
While I don't know which (if any) Python package manager will "win", I'm confident it won't be Conda or similar. I hope and pray not, anyway.
- matrss 2y ago
  Yes, the entire workflow of conda/mamba is a liability. Having environments detached from directories encourages bad practices (reusing environments for unrelated things, installing everything into the same environment and getting very broken dependency resolutions, that stuff) and it doesn't even have a lock file format, so environments can't be saved short of dumping its entire directory. Iff it must be the conda ecosystem, pixi (https://pixi.sh/latest/ https://pixi.sh/latest/) is a much better pick. But conda-style packages (or anything with install time dependency resolution really) also have the issue of being completely untestable. That makes them unsuitable at least for user-facing package management, if you care about your packages not randomly breaking without warning. I'd rather see every language converge on a single package manager that implements functional package management, i.e. guix or nix. One can dream...
  - skeledrew 2y ago
    I've been using a conda+poetry flow for years and it's worked very well. Particularly because envs aren't tied to projects. I tried pixi for a few days in a project months ago and it was just breakage and untenable limitations all around. I prefer the freedom of using per project envs when I want, and shared envs other times.
    - matrss 2y ago
      What are you using each of them for in that workflow? I've found that there really only are two kinds of packages I want to install: those I want globally (e.g. CLI tools like git, git-annex, DataLad, whatever shell enhancing you want, etc.) and project-specific dependencies (anything required to get going with it on a freshly installed system with the smallest amount of assumptions possible). The former is sufficiently addressed by `pixi global` and other package managers, the latter by pixi projects. Notably, conda environments are a bad fit for both (not global, not really updatable, not automatically tied to a project, not rebuildable due to missing lock files, ...).
      - thejevans 2y ago
notatallshaw 2y ago
> Please consider consolidating python dependency management instead of fragmenting it: https://github.com/mamba-org/mamba https://github.com/mamba-org/mamba Mamba doesn't even interact with the official python packing ecosystem... It is purely a conda replacement and conda packaging is not Python packaging (it's a more fundamental fragmentation than choosing a particular tool). So weird choice to not fragment Python dependency management. If you depend on both conda and standard Python packaging (e.g. PyPI.org) you can use Pixi: https://github.com/prefix-dev/pixi?tab=readme-ov-file#pixi-package-management-made-easy https://github.com/prefix-dev/pixi?tab=readme-ov-file#pixi-p.... Pixi attempts to bridge the conda world and the Python package world, so it's possible to rely more deeply on standards based packaging but still use conda tooling when you need it.

jonathrg 2y ago

How is uv, another flavor-of-the-month Python packaging tool, not contributing to fragmentation?

danglymarsh 2y ago
[flagged]
- alephxyz 2y ago
  Source? Never heard of it until today
  - colechristensen 2y ago
    I looked into uv a while back and it indeed was considerably faster than pip, but the folks who created it seem like they're trying a business around python tooling and are in the early stages. There is a risk of a rug pull of some kind down the road when they decide they want to make money and that to me was too much of a risk at present. https://astral.sh/about https://astral.sh/about
  - danglymarsh 2y ago
    [flagged]
    - alephxyz 2y ago
      I'm not gonna dig up someone's history to figure out what you mean. If you're going to make a throwaway account to insult someone at least be explicit about your accusations.
the_mitsuhiko 2y ago
uv unlike all other options has the best shot at becoming the one.
- kstrauser 2y ago

whalesalad 2y ago

This is not fragmenting it. The requirements.txt file has been a steady and well used API for well over a decade. This tool just helps you produce one for a project that is missing one.

ris 2y ago

How about you stop trying to create package managers for every single language/ecosystem in existence and instead converge on trying to solve the whole problem once and for all with Nix.

verandaguy 2y ago
Asking honestly since I've seen Nix and NixOS show up on the front page here a bunch over the years, but never used it: my impression of it is that it fills the same kind of niche as the Zig or Nim languages: conceptually pretty cool, but not widely adopted outside of a dedicated core user group. Is this really the case for Nix, or is it actually widely adopted, and this adoption is underreported? If it's not actually widely adopted, what do you think are the biggest obstacles in Nix's way?

jghn 2y ago

> Please consider consolidating python dependency management instead of fragmenting it You realize that this project predates uv by roughly a decade, right?

Terretta 2y ago
[flagged]
- chaps 2y ago
  Can you expand on what you mean, exactly?
  - throwaway314155 2y ago
    They thought they had a better advertising chance for `uv` than they actually did. As far as I can tell, `uv` is a replacement for `pip`. But the project linked by OP doesn't actually replace `pip`, but rather a small subset of functionality in `pip` - `pip freeze`. Unless `uv` has some sort of import scanning functionality, the suggestion to use `uv` instead doesn't really make any sense.
    - Terretta 2y ago
      On the contrary, read this about `uv` by the author of `rye`: https://lucumr.pocoo.org/2024/8/21/harvest-season/ https://lucumr.pocoo.org/2024/8/21/harvest-season/ Domination is a goal because it means that most investment will go into one stack. I can only re-iterate my wish and desire that Rye (and with it a lot of other tools in the space) should cease to exist once the dominating tool has been established. For me uv is poised to be that tool. It's not quite there today yet for all cases, but it will be in no time, and now is the moment to step up as a community and start to start to rally around it. Yes, I linked to an obscure feature uv supports. It's already a rather lot more.
      - throwaway314155 2y ago