Uv: Python Packaging in Rust

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • pixi

    Package management made easy

    Isn't this basically what pixi wants to be? Wouldn't it be better to work together?

    https://github.com/prefix-dev/pixi/

  • rfcs

    RFCs for changes to Rust

    Congrats!

    > Similarly, uv does not yet generate a platform-agnostic lockfile. This matches pip-tools, but differs from Poetry and PDM, making uv a better fit for projects built around the pip and pip-tools workflows.

    Do you expect to make the higher level workflow independent of requirements.txt / support a platform-agnostic lockfile? Being attached to Rye makes me think "no".

    Without being platform agnostic, to me this is dead-on-arrival and unable to meet the "Cargo for Python" aim.

    > uv supports alternate resolution strategies. By default, uv follows the standard Python dependency resolution strategy of preferring the latest compatible version of each package. But by passing --resolution=lowest, library authors can test their packages against the lowest-compatible version of their dependencies. (This is similar to Go's Minimal version selection.)

    > uv allows for resolutions against arbitrary target Python versions. While pip and pip-tools always resolve against the currently-installed Python version (generating, e.g., a Python 3.12-compatible resolution when running under Python 3.12), uv accepts a --python-version parameter, enabling you to generate, e.g., Python 3.7-compatible resolutions even when running under newer versions.

    This is great to see though!

    I can understand it being a flag on these lower level, directly invoked dependency resolution operations.

    While you aren't onto the higher level operations yet, I think it'd be useful to see if there is any cross-ecosystem learning we can do for my MSRV RFC: https://github.com/rust-lang/rfcs/pull/3537

    How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. Its something that Cargo is weak in today but we're slowly improving.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • rip

    Solve and install Python packages quickly with rip (pip in Rust) (by prefix-dev)

    There are a couple of promising tools written in Rust looking to replace Pip for most users.

    Rip (https://github.com/prefix-dev/rip/issues) which is more of a library for other rust tools to be on top of like Pixi (which is looking to replace both Pip and Conda).

    And now uv, which seems to be looking to replace Pip, Pip-Tools, and eventually Poetry and PDM.

    A lot of the explosion in tools in the Python world is coming from the desire for better workflows. But it has been enabled by the fact that build configuration and calling has been standardized and tool makers are able to follow standards instead of reverse engineering easy install or setup tools.

    I know a lot of people are put off by there being so many tools, but I think in a few years the dust will settle and there will emerge a best practice work flow that most users can follow.

    As a primarily Python developer and someone who occasionally contributes to Pip to solve complex dependency resolution issues it does make me wonder if I should hang my hat on that and learn enough rust to contribute to one of these projects eventually.

  • hatch

    Modern, extensible Python project management

    Exciting stuff! I view Hatch [1] as becoming the Cargo for Python because it's already close and has an existing (and growing) user base but I can definitely see depending on this for resolution and potentially not even using pip after it becomes more stable.

    [1]: https://hatch.pypa.io/latest/

  • pyflow

    An installation and dependency system for Python (by David-OConnor)

    Very cool! Of note, I made something along these lines a few years ago, although with a slightly broader scope to also include managing and installing python versions. I abandoned it due to lack of free time, and edge cases breaking things. The major challenge is that Python packages that aren't wheels can do surprising things due to setup.py running arbitrary code. (https://github.com/David-OConnor/pyflow)

  • Poetry

    Python packaging and dependency management made easy

    Has anyone else been paying attention to how hilariously hard it is to package PyTorch in poetry?

    https://github.com/python-poetry/poetry/issues/6409

  • black

    The uncompromising Python code formatter

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • uv

    An extremely fast Python package installer and resolver, written in Rust.

    https://github.com/astral-sh/uv?tab=readme-ov-file#multi-ver...

    says:

    > uv does not yet produce a machine-agnostic lockfile.

    so maybe the non-portable requirements.txt is just a first milestone

  • rye

    a Hassle-Free Python Experience

    I think Rye actually does handle this mostly correctly (as the sibling comment said). I got through some of it here: https://github.com/mitsuhiko/rye/issues/671. I think actually it's very close to what I actually want (maybe not what Armin wants with multiversion).

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts