4 ms·

You might be interested in pixi, which is roughly to conda as uv is to pip (also written in Rust, it reuses the uv solver for PyPI packages)

by embe42 11mo ago

th0ma5 11mo ago
This is something that uv advocates should pay attention to, there are always contexts that need different assumptions, especially with our every growing and complex pile of libraries and systems.
Difwif 11mo ago
Pixi has also been such a breathe of fresh air for me. I think it's as big of a deal as UV (It uses UV under the hood for the pure python parts). It's still very immature but if you have a mixture of languages (C, C++, Python, Rust, etc.) I highly recommend checking it out.
alfalfasprout 11mo ago
Yep, pixi is game changing. Especially for AI/ML, the ability to deal with non-python dependencies in nearly as fast a way as `uv` is huge. We have some exciting work leveraging the lower level primatives pixi uses we hope to share more about soon.
adastra22 11mo ago
I wish the Python ecosystem would just switch to Rust. Things are nice over here… please port your packages to crates.
- t43562 11mo ago
  I've never used a more hostile language than rust. Some people hate python and I can't understand why but such is life. One mans meat....
  - brabel 11mo ago
    I don’t really hate python but would absolutely never use it as a large code base main language. I think what people hate is other people trying to use a scripting language like Python in places where you have large code bases and large teams. Scripting languages in general are terrible for that as they give you almost no compile time guarantees about anything! But I always thought that for people whose main job is not programming and whose scripts don’t get larger than a couple of thousand lines, python is a good choice… though Lisp would perhaps be even better if historically it had gotten the huge mindshare and resulting ecosystem.
    - t43562 11mo ago
      It has been repeatedly seen as a scripting language because people saw it as a replacement for perl. Perl was the language of the big hack. It had very little to offer in the way of abstractions and OO. So you were kind of excused from writing well structured code and people wrote a lot of janky, untestable stuff in perl and carried on doing than in python. In python, to get good code you absolutely have to have unit tests and some kind of integration tests. I worked on a roughly 50,000 line python program. It wasn't bad even though we didn't have type hints then. Occasionally we did discover embarassing bugs that a statically typed language would not have permitted but we wrote a test and closed that door.
      - brabel 11mo ago
        Right, I know it is possible, but I have to ask why?? IF you can write a 50,000-line program, you probably could handle a better language for that. I'm on the side of wishing my languages did a lot more for me than they currently do! Rust is a good step, but I do find it taxing to write... I am currently considering some functional languages like Gleam (it compiles Erlang + JS and looks a bit like Elm, which is awesome but frontend only) and even more research stuff like Flix. But day to day, I am happy to write Kotlin and Dart :D they give you amazing tooling and just good enough type guarantees. Anyway, good to have a bunch of options :).
  - arw0n 11mo ago
    For me uv seems to solve some of the worst pain points of Python, which is great since I have to work with it. I think for a lot of people the hate comes in when they have to maintain or deploy Python code in scenarios that Python and its libraries wasn't designed to do. Some stuff just makes Python seem like an "unserious" programming language to me: 1. Installation & dependencies: Don't install Python directly, instead install pyenv, use pyenv to install python and pip, use pip to install venv, then use venv to install python dependencies. For any non-trivial project you have to be incredibly careful with dependency management, because breaking changes are extremely common. 2. Useless error messages: I cannot remember outside of trivial examples without external packages when the error message I got was actually directly pointing towards the issue in the code. To give a quick example (pointing back to the point above), I got the error message "ImportError: cannot import name 'ChatResponse' from 'cohere.types'". A quick google search reveals that this happens if a) the cohere API-Key isn't set in ENV or b) you use langchain-cohere 0.4.4 with cohere 5.x, since the two aren't compatible. 3. Undisciplined I/O in libraries: Another ML library I recently deployed has a log-to-file mode. Fair enough, should be disabled before k8s deployment no biggie. Well, the library still crashes because it checks if it has rwx-permissions on a dir it doesn't need. 4. Type conversions in C-interop: Admittedly I was also on the edge of my own capabilities when I dealt with these issues, but we had issues with large integers breaking when using numpy/pandas in between to do some transforms. It was a pain to fix, because Python makes it difficult to understand what's in a variable, and what happens when it leaves Python. 1. and 4. are mainly issues with people doing stuff in Python it wasn't really designed to do. Using Python as a scripting language or a thin (!) abstraction layer over C is where it really shines. 2. and 3. have more to do with the community, but it is compounded by bad language design.
    - kortex 11mo ago
      1. is true, yup people have been ragging on the python install superfund site problem for years, but the rest of those are entirely 3rd party library issues. It's like saying Windows is not a serious operating system because you installed a buggy application. 2. I've used a ton of languages and frankly Python has the best tracebacks hands-down, it's not even close. It's not Python's fault a 3rd party library is throwing the wrong error. 3. Again, why is bad language design a library can do janky things with I/O? 4. FFI is tricky in general, but this sounds like primarily a "read the docs" problem. All of the major numeric acceleration libraries have fixed sized numbers, python itself uses a kind of bigint that can be any size. You have to stay in the arrays/tensors to get predictable behavior. This is literally python being "a thin abstraction layer over C."
  - moi2388 11mo ago
    Because it isn’t a statically typed language, is terribly, terribly slow, has horrible production environments and has a lot of quirks? I don’t understand why anybody would ever develop anything in Python other than “I want to write software but can’t be arsed to follow software design principles”, with all the mess that follows from it.
    - daedrdev 11mo ago
      Congrats on finding the reason: its easier in python
      - moi2388 11mo ago
        Only in the short term
- atty 11mo ago
  The unspoken assertion that Rust and Python are interchangeable is pretty wild and needs significant defense, I think. I know a lot of scientists who would see their first borrow checker error and immediately move back to Python/C++/Matlab/Fortran/Julia and never consider rust again.
- omgmajk 11mo ago
  > please port your packages to crates. This is such a deeply unserious take. Do you have hundreds of thousands of hours to give out for free? No?
icar 11mo ago
This seems to pretty much cover the same use cases as Mise. Is that true?
- suslik 11mo ago
  The main difference between mise and pixi is an ability to subscribe to conda channels and build (in an extremely fast way) conda environments, bypassing or eliminating most of the conda frustration (regular conda users know what I mean). mise allows to install asdf tools primarily (last I checked). On the python front, however, I am somehow still an old faithful - poetry works just fine as far as I was every concerned. I do trust the collective wisdom that uv is great, but I just never found a good reason to try it.
exasperaited 11mo ago
Pixi is what FreeCAD is now using. (Along with Rattler). It makes building FreeCAD pretty trivial, which is a huge deal considering FreeCAD’s really complex Python and non-python, cross-platform dependencies.

You might be interested in pixi, which is roughly to conda as uv is to pip (also written in Rust, it reuses the uv solver for PyPI packages)

by embe42 11mo ago

You might be interested in pixi, which is roughly to conda as uv is to pip (also written in Rust, it reuses the uv solver for PyPI packages)

th0ma5 11mo ago

This is something that uv advocates should pay attention to, there are always contexts that need different assumptions, especially with our every growing and complex pile of libraries and systems.

Difwif 11mo ago

Pixi has also been such a breathe of fresh air for me. I think it's as big of a deal as UV (It uses UV under the hood for the pure python parts). It's still very immature but if you have a mixture of languages (C, C++, Python, Rust, etc.) I highly recommend checking it out.

alfalfasprout 11mo ago

Yep, pixi is game changing. Especially for AI/ML, the ability to deal with non-python dependencies in nearly as fast a way as `uv` is huge. We have some exciting work leveraging the lower level primatives pixi uses we hope to share more about soon.

adastra22 11mo ago

I wish the Python ecosystem would just switch to Rust. Things are nice over here… please port your packages to crates.

t43562 11mo ago
I've never used a more hostile language than rust. Some people hate python and I can't understand why but such is life. One mans meat....
- brabel 11mo ago
  I don’t really hate python but would absolutely never use it as a large code base main language. I think what people hate is other people trying to use a scripting language like Python in places where you have large code bases and large teams. Scripting languages in general are terrible for that as they give you almost no compile time guarantees about anything! But I always thought that for people whose main job is not programming and whose scripts don’t get larger than a couple of thousand lines, python is a good choice… though Lisp would perhaps be even better if historically it had gotten the huge mindshare and resulting ecosystem.
  - t43562 11mo ago
    It has been repeatedly seen as a scripting language because people saw it as a replacement for perl. Perl was the language of the big hack. It had very little to offer in the way of abstractions and OO. So you were kind of excused from writing well structured code and people wrote a lot of janky, untestable stuff in perl and carried on doing than in python. In python, to get good code you absolutely have to have unit tests and some kind of integration tests. I worked on a roughly 50,000 line python program. It wasn't bad even though we didn't have type hints then. Occasionally we did discover embarassing bugs that a statically typed language would not have permitted but we wrote a test and closed that door.
    - brabel 11mo ago
      Right, I know it is possible, but I have to ask why?? IF you can write a 50,000-line program, you probably could handle a better language for that. I'm on the side of wishing my languages did a lot more for me than they currently do! Rust is a good step, but I do find it taxing to write... I am currently considering some functional languages like Gleam (it compiles Erlang + JS and looks a bit like Elm, which is awesome but frontend only) and even more research stuff like Flix. But day to day, I am happy to write Kotlin and Dart :D they give you amazing tooling and just good enough type guarantees. Anyway, good to have a bunch of options :).
- arw0n 11mo ago
  For me uv seems to solve some of the worst pain points of Python, which is great since I have to work with it. I think for a lot of people the hate comes in when they have to maintain or deploy Python code in scenarios that Python and its libraries wasn't designed to do. Some stuff just makes Python seem like an "unserious" programming language to me: 1. Installation & dependencies: Don't install Python directly, instead install pyenv, use pyenv to install python and pip, use pip to install venv, then use venv to install python dependencies. For any non-trivial project you have to be incredibly careful with dependency management, because breaking changes are extremely common. 2. Useless error messages: I cannot remember outside of trivial examples without external packages when the error message I got was actually directly pointing towards the issue in the code. To give a quick example (pointing back to the point above), I got the error message "ImportError: cannot import name 'ChatResponse' from 'cohere.types'". A quick google search reveals that this happens if a) the cohere API-Key isn't set in ENV or b) you use langchain-cohere 0.4.4 with cohere 5.x, since the two aren't compatible. 3. Undisciplined I/O in libraries: Another ML library I recently deployed has a log-to-file mode. Fair enough, should be disabled before k8s deployment no biggie. Well, the library still crashes because it checks if it has rwx-permissions on a dir it doesn't need. 4. Type conversions in C-interop: Admittedly I was also on the edge of my own capabilities when I dealt with these issues, but we had issues with large integers breaking when using numpy/pandas in between to do some transforms. It was a pain to fix, because Python makes it difficult to understand what's in a variable, and what happens when it leaves Python. 1. and 4. are mainly issues with people doing stuff in Python it wasn't really designed to do. Using Python as a scripting language or a thin (!) abstraction layer over C is where it really shines. 2. and 3. have more to do with the community, but it is compounded by bad language design.
  - kortex 11mo ago
    1. is true, yup people have been ragging on the python install superfund site problem for years, but the rest of those are entirely 3rd party library issues. It's like saying Windows is not a serious operating system because you installed a buggy application. 2. I've used a ton of languages and frankly Python has the best tracebacks hands-down, it's not even close. It's not Python's fault a 3rd party library is throwing the wrong error. 3. Again, why is bad language design a library can do janky things with I/O? 4. FFI is tricky in general, but this sounds like primarily a "read the docs" problem. All of the major numeric acceleration libraries have fixed sized numbers, python itself uses a kind of bigint that can be any size. You have to stay in the arrays/tensors to get predictable behavior. This is literally python being "a thin abstraction layer over C."
- moi2388 11mo ago
  Because it isn’t a statically typed language, is terribly, terribly slow, has horrible production environments and has a lot of quirks? I don’t understand why anybody would ever develop anything in Python other than “I want to write software but can’t be arsed to follow software design principles”, with all the mess that follows from it.
  - daedrdev 11mo ago
    Congrats on finding the reason: its easier in python
    - moi2388 11mo ago
      Only in the short term
atty 11mo ago
The unspoken assertion that Rust and Python are interchangeable is pretty wild and needs significant defense, I think. I know a lot of scientists who would see their first borrow checker error and immediately move back to Python/C++/Matlab/Fortran/Julia and never consider rust again.
omgmajk 11mo ago
> please port your packages to crates. This is such a deeply unserious take. Do you have hundreds of thousands of hours to give out for free? No?

icar 11mo ago

This seems to pretty much cover the same use cases as Mise. Is that true?

suslik 11mo ago
The main difference between mise and pixi is an ability to subscribe to conda channels and build (in an extremely fast way) conda environments, bypassing or eliminating most of the conda frustration (regular conda users know what I mean). mise allows to install asdf tools primarily (last I checked). On the python front, however, I am somehow still an old faithful - poetry works just fine as far as I was every concerned. I do trust the collective wisdom that uv is great, but I just never found a good reason to try it.

exasperaited 11mo ago

Pixi is what FreeCAD is now using. (Along with Rattler). It makes building FreeCAD pretty trivial, which is a huge deal considering FreeCAD’s really complex Python and non-python, cross-platform dependencies.