5 ms·

I hadn't paid any attention to rust before uv, but since starting to use uv, I've switched a lot of my performance-sensitive code dev to rust (with interfaces t

• gostsamo 1y ago
  As far as I get it, conda is still around because uv is focused on python while conda handles things written in other languages. Unless uv gets much more universal than expected, conda is here to stay.
  • tempay 1y ago
    There is also pixi (which uses uv for the python side of things) which feels like uv for conda.
    • okanat 1y ago
      Pixi is great! It doesn't purely use uv though. I just love it. It solves "creating a repo that runs natively on any developer's PC natively" problem quite well. It handles different dependency trees per OS for the same library too!
  • prpl 1y ago
    conda (and its derivatives that are also “conda” now), and conda-forge specifically, are the best ways to install things that will work across operating systems, architectures, and languages - without having to resort to compiling everything. Want to make sure a software stack works well on a Cray with MPI+cuda+MKL, macOS, and ARM linux, with both C++ and Python libraries? It’s possible with conda-forge.
    • levocardia 1y ago
      Except the ONE annoying quirk that certain major projects and repos let their conda distribution get stale.
    • kombine 1y ago
      For me the best way to install things across operating systems has been nix. I wish it was more popular in the ML community.
    • the__alchemist 1y ago
      You can do all of the above with Wheels.
      • prpl 1y ago
        Can you show me someone who has packaged log4cxx in a wheel? Is it in pip? Arbitrary examples, I know, but I moved a large software that was truly mixed C++ and python project to conda-forge and all sorts of random C++ dependencies were in there, which drastically simplified distribution and drastically reduced compile time. If I had done it today, it might be nix+bazel, or maybe conda+bazel, but maintaining a world of C++ libraries for distribution as wheels does not sound like fun - especially because nobody is doing that work as a community now
        • the__alchemist 1y ago
          I wrap Rust/CUDA programs in wheels. I've packaged arbitrary binaries in wheels, like software that's not directly related to Python. Can't say it works for everything, but I suspect so. You just run `maturn build`, then it can be installed with pip. Conda is like Jquery or Bootstrap: It was necessarily before the official tools evolved. Now we don't need them any more, but they still are around for legacy reasons. You still need it for example, for some Moleular dynamics packages, but that's due to the package publishers choosing it.
    • neves 1y ago
      Conda is hell for multi operationg systems projects. Its lock file is OS dependent. You can't commit it and hope it will work anywere. It is probably the easiest way to install a lot of binary dependencies, good for who doesn't have experience with sofware development and don't care with reproductbility.
• embe42 1y 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 1y 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 1y 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 1y 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 1y ago
    I wish the Python ecosystem would just switch to Rust. Things are nice over here… please port your packages to crates.
    • t43562 1y 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 1y 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.
• kardos 1y ago
  It would be nice indeed if there was a good solution to multi-gigabyte conda directories. Conda has been reproducible in my experience with pinned dependencies in the environment YAML... slow to build, sure, but reproducible.
  • PaulHoule 1y ago
    I'd argue bzip compression was a mistake for Conda. There was a time when I had Conda packages made for the CUDA libraries so conda could locally install the right version of CUDA for every project, but boy it took forever for Conda to unpack 100MB+ packages.
    • kardos 1y ago
      It seems they are using zstd now for .conda packages, eg, bzip is obsoleted, so that should be faster.
  • blactuary 1y ago
    uv does it by caching versions of packages so they can be shared across projects/environments. So you still have to store those multi-gig directories but you don't have so much duplication. If conda could do something similar that would be great
• whimsicalism 1y ago
  I work professionally in ML and have not had to touch conda in the last 7 years. In an ML cluster, it is hopefully containerized and there is no need for that?
  • BoredPositron 1y ago
    It's still used in edu and research. Haven't seen it in working environments in quite some time as well.
  • dekhn 1y ago
    At least on my cluster, few if any workloads are containerized. We also have an EKS where folks run containerized, but that's more inference and web serving, rather than training.
  • jscyc 1y ago
    Very common in education/research systems. Even the things which are containerised often have conda in them.
  • disgruntledphd2 1y ago
    > I work professionally in ML and have not had to touch conda in the last 7 years. In an ML cluster, it is hopefully containerized and there is no need for that? I wish my life had been like this. Unfortunately I always appear to end up needing to make this stuff work for everyone else (the curse of spending ten years on Linux, I suppose). But then ML is a very broad church, and particularly if you're a researcher in a bigger company then I could see this being true for lots of people (again, i wish this was me).
• savin-goyal 1y ago
  the topic of managing large dependency chains for ML/AI workloads in a reproducible has been a deep rabbit hole for us. if you are curious, here is some of the work in open domain https://docs.metaflow.org/scaling/dependencies https://docs.metaflow.org/scaling/dependencies https://outerbounds.com/blog/containerize-with-fast-bakery https://outerbounds.com/blog/containerize-with-fast-bakery
• jvanderbot 1y ago
  Obligatory: Not only rust would be faster than python, but Rust definitely makes it easy with Cargo. Go, C, C++ should all exhibit the performance you are seeing in uv, if it had been written in one of those languages. The curmudgeon in me feels the need to point out that fast, lightweight software has always been possible, it's just becoming easier now with package managers.
  • dekhn 1y ago
    I've programmed all those languages before (learned C in '87, C++ in 93, Go in 2015 or so) and to be honest, while I still love C, I absolutely hate what C++ has become, Go never appealed to me (they really ignored numeric work for a long time). Rust feels like somebody wanted to make a better C with more standard libraries, without going the crazy path C++ took.
    • jvanderbot 1y ago
      That is exactly how I feel about it. I've always loved C for it's simplicity and Rust felt like an accidental love letter.
    • okanat 1y ago
      I actually got interested in Rust because its integer types and the core data structures looked sane, instead of this insanity: https://en.cppreference.com/w/cpp/types/integer.html https://en.cppreference.com/w/cpp/types/integer.html . Fluid integer types are evil. I stayed for the native functional programming, first class enums, good parts of C++ and the ultimate memory safety.
    • krzyk 1y ago
      Also this. I liked C (don't use it now, right now it is mostly Java) but C++ didn't appeal to me. Rust is for me similar to C just like you wrote, it is better, bigger but not the overwhelming way like C++ (and Rust has cargo, don't know if C++ has anything).
    • t43562 1y ago
      OO is supposed to make life easier but C++ exposes all the complexity of the implementation to you. Its approach to hiding complexity is to shove it partially under a carpet with sharp bits sticking out.
• oofbey 1y ago
  Have you found it easy to write rust modules with python interfaces? What tools do you recommend?
  • ederamen 1y ago
    I'd be interested in this too. I know it's possible, but haven't found a good guide on how to do it well and manage the multi-lang complexity.
  • sbt567 1y ago
    Many people use PyO3 for that
  • oconnor663 1y ago
    PyO3 and Maturin are excellent. I've been maintaining a Python-module-written-in-Rust for several years now, and it's been quite smooth.
  • the__alchemist 1y ago
    PyO3 + Maturn is fine, but it's a bit tedious if you have a big API. Some annoyances: - Enums with inner types require hacks - No clean way to make your Rust enums into Python enums - More boilerplate than you should have. I think I will have to write my own macros/helpers to solve. For example, you need getters and setters for each field. And the gotcha: You can't just macro them due to a PyO3 restriction. - No way to use other Python-exposed rust libs as dependencies directly. You have to re-expose everything. So, if your rust B lib depends on rust A, you will make a PyO3 Rust A package, but instead of re-using that in PyO3 Rust B, you will copy+paste your PyO3 Rust A boilerplate into PyO3 Rust B. If you're maintaining a single lib and want to expose it to Python, it's fine once you find a pattern that works. If you have a network and/or your API is large or not stable, it's a mess. (but doable)
• warbaker 1y ago
  Have you figured out a good way to manage CUDA dependencies with uv?
  • persedes 1y ago
    https://docs.astral.sh/uv/guides/integration/pytorch/#using-a-pytorch-index https://docs.astral.sh/uv/guides/integration/pytorch/#using-... does that fit the bill?
    • okanat 1y ago
      Not the OP but does this actually package CUDA and the CUDA toolchain itself or just the libraries around it? Can it work only with PyTorch or "any" other library? Conda packaging system and the registry is capable of understanding things like ABI and binary compatibility. It can resolve not only Python dependencies but the binary dependencies too. Think more like dnf, yum, apt but OS-agnostic including Windows. As far as I know, (apart from blindly bundling wheels), neither PyPI nor Python packaging tools have the knowledge of ABIs or purely C/C++/Rust binary dependencies. With Conda you can even use it to just have OS-agnostic C compiler toolchains, no Python or anything. I actually use Pixi for shipping an OS-agnostic libprotobuf version for my Rust programs. It is better than containers since you can directly interact with the OS like the Windows GUI and device drivers or Linux compositors. Conda binaries are native binaries. Until PyPI and setuptools understand the binary intricacies, I don't think it will be able to fully replace Conda. This may mean that they need to have an epoch and API break in their packaging format and the registry. uv, poetry etc. can be very useful when the binary dependencies are shallow and do not deeply integrate or you are simply happy living behind the Linux kernel and a container and distro binaries are fulfilling your needs. When you need complex hierarchies of package versions where half of them are not compiled with your current version of the base image and you need to bootstrap half a distro (on all OS kernels too!), Conda is a lifesaver. There is nothing like it.
      • dekhn 1y ago
        If I find myself reaching a point where I would need to deal with ABIs and binary compatiblity, I pretty much stop there and say "is my workload so important that I need to recompile half the world to support it" and the answer (for me) is always no.
• miki123211 1y ago
  As a person who has successfully used uv for ml workloads, I'm curious what makes you still stay with Conda.
  • disgruntledphd2 1y ago
    Conda is much, much better for the C/Fortran/C++ parts of data science/machine learning workloads. Like, I had real issues with GDAL and SQLite/spatialite on MacOS (easy on Linux) which uv was of no help with. I ended up re-architecting rather than go back to conda as uv is just that good (and it was early stage so wasn't that big of a deal).
  • insane_dreamer 1y ago
    cuda-nvcc was a blocker for us but it looks like a stable version is coming to pypi
  • blactuary 1y ago
    I stay with it because last time I tried uv it was still directory/project focused vs. environment. With conda it doesn't matter where I am, I can activate any of my environments and run code