[charliermarsh]

A lot of our core packaging development is now happening in uv [1]. Rye uses uv under the hood, so as we improve uv, Rye gets better too.

E.g., we recently added support for "universal" resolution in uv, so you can generate a locked requirements.txt file with a single resolution that works on all platforms and operating systems (as opposed to _just_ the system you're running on). And Rye supports it too in the latest release.

[1] https://github.com/astral-sh/uv

---

I work on Rye and uv, if you have any questions :)

[smnrchrds]

Does Rye/UV with universal resolution work properly with PyTorch, or does it suffer from the same issue as Poetry?

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

https://news.ycombinator.com/item?id=39257501

[catwell]

It works properly with PyTorch. For what it's worth at $DAYJOB we switched from Poetry to Rye starting from version 0.15 (even before it supported uv) for that reason initially.

[smnrchrds]

That is encouraging to hear. I am curious specifically about the universal resolution feature that has been newly added. Poetry's issue is that it cannot properly resolve PyTorch's more complicated situation. I imagine Rye before this change would have used pip under the hood, so it would have worked as well as pip. I hope this still holds with the new under-the-hood changes.

[arthur-st]

Any ongoing work/plans to follow for cross-platform lock files?

This is one concern that would prevent the team I'm on from moving. We do ML work, so I'll use a pytorch-based project for my example. The desired state is that all dependencies are in pyproject.toml, e.g., from which you can generate a set of lockfiles from an AArch64 Mac or an AMD64 Windows workstation for the following platform configurations:

1. Mac with default (MPS) pytorch

2. Windows with CUDA pytorch

3. AArch64 Linux with CPU pytorch

4. AMD64 Linux with CPU pytorch

5. AMD64 Linux with CUDA pytorch

P.S. Big thanks for making Ruff, we're huge fans of linting and formatting both.

[ewolf]

I have almost the same problem. With Poetry, I managed to work around it using this technique, involving a combination of groups and extras: https://github.com/lucaspar/poetry-torch

It's a hacky workaround, but it seems to work so far. It would be much nicer to see this solved in a better way, though!

[LarsDu88]

Poetry does cross platform lockfiles, but the absence of cross platform lockfiles is one of the reasons why uv benchmarks significantly faster (on top of using Rust for the resolve)

[arthur-st]

Unfortunately, installing pytorch via Poetry was not for the faint of heart, last I tried. [1]

For example, it used to download wheels for all matching distributions (say pytorch for a few platforms) to get metadata. That would be like a 10 GB download for 4 wheels of pytorch, to generate the lockfile.

Another thing it used to do is ignore local cache, so for some locking operations would download the same wheel multiple times.

In general, it was not entertaining, from an ML practitioner's perspective, to infer an attitude from the Poetry maintainers that the mountain shall come to Muhammad, so to say. Their abridged position was that pytorch is not compliant with standards, when Poetry itself, e.g., is not PEP 440-compliant, in a manner pertinent to the issue at hand. [2]

I realise that my grumbling about pytorch has nothing to do with your perfectly adequate comment, that said. Please interpret it as nothing more than an expanded rationale fore being more interested in learning about Rye/uv than in revisiting Poetry, at least for the projects I've worked on.

[1] https://github.com/python-poetry/poetry/issues/6409

[2] https://github.com/python-poetry/poetry/issues/7748

[LarsDu88]

My experience is that both PyTorch and Tensorflow are incredibly fickle with the interplay between cuda versioning and python package versioning.

You need to go straight into their websites and manually figure out what goes with what.

Quite honestly, this needs to be done in Docker with fancy conditional logic, and not via the python package manager.

[arthur-st]

Speaking about strictly PyTorch, it's actually elementary on the distribution side. I know that there are packages which do some weird setup magic at runtime, unfortunately, but pytorch is not one of them.

Installing it via the PyPI gets you the CPU version on Windows/macOS, and CUDA 12.1 on Linux. You can specify CUDA version explicitly, which you need to get CUDA on Windows, or CUDA 11.8 on Linux, by referencing the corresponding PyTorch package index, e.g., https://download.pytorch.org/whl/cu118 - cu118 means CUDA 11.8. Doing that explicitly is the normal practice, since in ML land you'll know your hardware well - no one is asking for tooling that automatically resolves CUDA/cuDNN/etcetra compatibility.

Hence, it hopefully follows that installing this with pip is trivial, you just need to maintain multiple requirements.txt files so that you specify the correct index URL where it's necessary. What I specifically want, then, is for someone to give me a UX where I don't have to maintain these requirements.txt files. I should be able to just specify arbitrary build environments* in pyproject.toml, and override the global default package index for specific packages in [platform-]specific build environments.

*Really, we're probably talking about combining blocks of optional dependencies into an ersatz build environment, but that's what they ultimately are for.

If I can then "compile" these build environments into properly reproducible lock files, and then use the dependency manager to export these lock files into conventional requirements.txt files with exact pins, then we've arrived at what I would call a good UX for specifying dependencies in Python.

To the best of my knowledge, for 99.9% of packages this doesn't require Docker. Different parts of this process work well across the ecosystem, just not as a matter of full package. To name a few

- Poetry has many building blocks, but just has had a questionable implementation as per parent you're replying to, and also random other problems like not working at all with private indexes back when I tried, and so on;

- pip-tools does the entire pipeline well, but it quite unfortunately doesn't support cross-platform targeting;

So, quite honestly, until someone can do this correctly and in one place - and, ideally, with endorsements from PSF and PyPA - I'll just consider Python dependency management tooling to be inadequate for my use cases.

[arthur-st]

I guess I'll add that this is mostly possible using a Docker-based workflow, but the hope is that one day we could get something more lightweight.

[HelloNurse]

Requiring Docker implies that a packaging tool is too simplistic to do its job.

[arthur-st]

Well, that's my question - I'm not familiar with Rye/uv, and I'm curious to know if it can substantively simplify the workflows that I'm aware of. I simply clarified to pre-empt a potential comment about Docker.

[VagabundoP]

Great work. I've switched to using Rye now as I used to have to occasionally setup a new computer to work on a project and it was always a complete pain (pyenv+venv+pip).

Now its:

* Install Rye,

* Pull from Github,

* Type rye sync

[pen2l]

Given that you guys are in charge of both uv and rye, why keep two alive at the same time? Why not just kill rye now to avoid fragmentation, and confusion that comes with the burden of having to choose between the two?

[the_mitsuhiko]

UV doesn’t do all these things yet. The end goal is that UV can fully replace Rye and a neat migration will be provided so that one can move over.

Since Rye already uses uv behind the scenes there won’t be a lot of incompatibilities to deal with so the migration should be trivial.

[semi-extrinsic]

I love Rye, especially with UV, and we are rolling it out where I work.

Question: are there any plans to add sandboxing support to Rye or UV? I realize it is a big ask and that it might not be possible on all platforms.

My dream scenario is that I can define a section in pyproject.toml that goes like

  [sandbox]  
  allowed_urls = [...]  
  allowed_dirs = [".",...]

and then "rye run" wraps the executed code in a sandbox which forbids the code to access anything outside those two whitelists. This would make me sleep so much better at night, as it solves 99% of my supply chain attack fears. And it's lightweight enough from the user side that it will actually be used.

[the_mitsuhiko]

No plans. That said, independently I have been thinking about this quite a bit since Deno has demonstrated that there is interest in stuff like that. Unfortunately to make that work in Python would require significant changes to Python itself.

[semi-extrinsic]

What I'm thinking about would technically be language independent, just a wrapper that is interposed between Rye and the Python interpreter to apply something like a seccomp filter to the Python interpreter (and all code that it calls). The wrapper could equally well be used on a piece of C code or whatever. But I'm sure you have a far better understanding than me of whether something like that is feasible :)

[rangerelf]

That sounds like a job for "firejail", at least in linux. Implementing that as part of python would be a major undertaking, and I wouldn't necessarily trust it, I'd prefer an external tool implement the sandbox.

[VWWHFSfQ]

Is there a technology in existence that would facilitate this from userspace and wouldn't require elevated kernel privileges to set caps?

[semi-extrinsic]

From my cursory googling, I believe seccomp on Linux is one way to achieve this. See e.g. Cloudflare's "sandbox" wrapper:

https://github.com/cloudflare/sandbox

FWICT, it's not possible to achieve something like this reliably on Windows natively, but maybe in WSL it could work. On Mac, there is the similar libsecinit aka App Sandbox which also can be spawned from a userspace process, I think?

Of course in every case the program spawning the sandbox has to be outside the sandbox. But having to trust Rye or UV is much better than having to trust thousands of "RandomDevsNichePythonPackage".

[rfoo]

IIUC, uv is a replacement for pip (?), and rye is for pyenv+poetry.

[baggiponte]

In the end, uv will be the pyenv + poetry replacement, and supersede rye.

[Joeboy]

So which should I use for a new project, as of July 2024?

[sali0]

Rye is perfectly fine to use as of now. It uses uv under the hood anyway, but has some niceties of its own.

[remram]

For example?

[kzrdude]

I would use Uv - if you can handle that it's a moving target right now. (uv python, uv lock, uv sync and so on, and in pyproject tool.uv.sources). All preview features that replace similar Rye features with a more robust implementation.

[PufPufPuf]

Poetry.

[VagabundoP]

I would.

[Terretta]

You have a lot of firms that care about predictable and performant building that are shifting to you, and one of the things that comes up is SBOM generation for ingestion into tools like guac.

https://guac.sh/

https://pypi.org/project/sbom4python/ https://github.com/CycloneDX/cyclonedx-python

Your recently added ability to unpin dependencies so devs are more encouraged to stay compatible as they dev, then generate a correct explicit requirements.txt for reproducibility, makes both vuln management and the SBOM step a far easier thing than poetry etc.

Thank you!

For similar reasons, we use https://hatch.pypa.io/latest/why/ and appreciate that it plays nicely with `uv`.

[vaylian]

> I work on Rye and uv, if you have any questions :)

How do you pronounce "uv"?

[crucialfelix]

Rhymes with bruv. London pronunciation

[batisteo]

No idea how a londonian prononces bruv. How about IPA?

[welpo]

/bɹʌv/

[crucialfelix]

How do you notate that the v is aspirated? It's practically an f

[satvikpendem]

Like the American pronunciation of "of".

[zanie]

We say "you - vee" :)

[satvikpendem]

Like ultraviolet? What's the origin of the name?

[timothylaurent]

I assume this "Universal" resolution is enabled by adding the "--universal" cli argument?

It doesn't look like this is currently documented but I found some hints in the release notes.

[germandiago]

How does it compare to Pipenv and Poetry? I had some problems every time I used Poetry. I wanted to like it but it hanged or took forever and similar things often.

[VagabundoP]

So dep resolution is fast with uv.

Setting up a new project is: rye init && rye sync Adding a dep is: rye add flask && rye sync You can pin your python version in the pyproject.toml

Migrating from an established project is a little hard than it should be. Importing the requirements.txt into the pyproject.toml is not a good idea as uv gets itself in a twist with all the low-level dependencies that exist in the requirements.txt. I've never tried it with a poetry made pyproject.toml, report back if you try it.

On the whole its a good experience, fast and straight forward.

[andybak]

> Importing the requirements.txt into the pyproject.toml is not a good idea as uv gets itself in a twist with all the low-level dependencies that exist in the requirements.txt.

Can you explain? I wonder if you mean "requirements.txt generated via pip freeze" rather than "a human curated requirements.txt"

[VagabundoP]

Yeah you're right.

If you just keep the requirements.txt "high level" then you should be okay. Just my experience with uv hanging for ages with a pip freeze made requirements file.

[jscheel]

This is awesome. I’ve really struggled with cross-platform resolutions in my bazel setup, as our services are built for containers that run in k8s, but we also want to be able to build and run locally for scripts, tests, etc. I have a branch that uses PDM, which works much better, but there are still a ton of hacks in it. Rye looks like it could help quite a bit.

[fire_lake]

How can you generate a universal lock file when some packages will query the running system in arbitrary ways during resolution?

[jvolkman]

Most packages don't do that. You can get really far by assuming that all of a package's wheels have the same set of dependencies (maybe using environment markers), and that its sdist always returns the same list of dependencies (also maybe using environment markers). No, it's not perfect, but it's also what Poetry and PDM do as far as I know.

[charliermarsh]

Yeah that's right -- we make the assumption that all distributions for a given package will yield the same dependencies, similar to Poetry, PDM, and other tools. This is not strictly required by the standards, but it's very rare for it to be violated.

[hobofan]

It's rare, but in my experience it can still be very impactful and hindering adoption.

E.g. that practice seems to be quite prevalent in a few high-profile pytorch packages, which caused our team a lot of pain when trying to enable reproducible cross-platform builds 1-2 years ago

[fire_lake]

Indeed. I gave up on this and just build in Docker.

[crabbone]

I like how you ignore the "best practices" for packaging created by PyPA (i.e project.toml and friends) and just do requirements.txt cowboy stuff.

Don't get me wrong, both are hilariously bad, but I like to see more chaos in Python infrastructure. You pushing against PyPA (rightfully) delegitimizes them.

[ipsum2]

What's the relationship between uv and uvloop?

[Leynos]

None. "UV" was chosen because it is short and available.

[boffinAudio]

How is it available if libuv?

[ziml77]

They probably mean that it didn't conflict with other common executables. I guess it could be a problem if libuv ever includes an executable called uv, though I can't imagine how it would make sense for libuv to have an executable component like that.

[OutOfHere]

I can do this with pip-tools. Exactly how does one enable this in rye?