Hacker News Reader

Comment by pen2l | Hacker News Reader

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?

View on HN

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.

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.

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.

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 :)

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.

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

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".

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

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

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

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

For example?

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.

Poetry.

I would.

Reply on news.ycombinator.com