HN Explorer

13 comments

[ 3.7 ms ] story [ 35.3 ms ] thread
charcircuit
"uv run" seriously needs a sandbox. Running arbitrary code from arbitrary dependencies with 0 version locking provides no guarantees on what you are actually running.
BiteCode_dev
uv run is using virtual envs, that's the de facto standard, and those are sandboxes for python deps. So it already is.

Plus inline deps mean you can pin python versions and 3rd party modules using pyproject.toml syntax in a comment of your script. This is not perfect locking, as it doesn't pin sub dependencies, but it's already more that any other tool out there.

If you want perfect locking, create a project, and use uv lock. You are already in a different category of code.

rjh29
That's the job of docker or systemd-nspawn. It shouldn't be implemented by every single command.
mvieira38
Why is it their job to check for security? Sandboxing would make the ergonomics significantly worse for running quick scripts with uv run --script
kortex
It might be a cool thing for them to provide some kind of container metadata in the `# /// script` block so that e.g. it automatically runs the script in a container.
vs4vijay
Maybe use along with "Pyodide"?
drewbitt
I have seen several Pyodide in Deno implementations lately.
paulbirch
This is an interesting development, especially considering the growing trend of code-sharing platforms. As others have pointed out, this move by GitHub to allow UV to run GitHub Gists blurs the lines between code hosting and execution environments. It's worth noting that this also puts UV in direct competition with other code execution services like Repl. it and Google Colab, both of which have been gaining traction in the developer community. I'm curious to see how UV will differentiate itself in this crowded space.
kelsolaar
Mmmmh I have been running from gists for ages, just use the full url as parameter...