> This is neat writeup on use of uv, but it doesn't solve the "how to give self contained script to grandma" problem.
Not at the moment, but will your grandma run a script? There is an interesting thing you can already do today for larger applications which is to install uv alongside your app. You can make a curl-to-bash thing or similar that first installs uv into a program specific location to then use that to bootstrap your program. Is it a good idea? I don't know, but you can do that.
For simple scripts (I never succeeded using it on something really complex, but it's great when you don't want to use bash but need something like Python) I had used this approach that still works nowadays and has no uv dependency (only requires pip to be installed in the same Python interpreter that you're using to run your script):
You can write a bash shebang that curl into shell. Unfortunately when I did it and gave to grandma it has failed because grandma has substituted oil shell and linked it as sh which is not best practice. I think grandmother shell script is simply impossible. They have spent decades acquiring idiosyncratic unix environment
Good thing those days init is systemd instead of a series of de jure POSIX shell scripts but de facto bashism shell scripts that will fail to boot if you swap /bin/sh away from bash.
At least ubuntu helped force the ecosystem to at least pretend to support /bin/dash too.
For this case, it might be easier to package the script using pyinstaller. That way, she can just run it. Packaging it that way is more work on your side though.
It automatically downloads interpreters from some internet source. It's a security nightmare. It can be configured not to do that but it's not the default.
I'm not sure that's fair. It downloads standalone builds which astral themselves maintain. I'd say they're pretty trust-worthy.
If you're worried about installing code from internet sources, which I think is valid, then pip/uv/package-managers-in-general open cans of worms anyway.
> I'm not sure that's fair. It downloads standalone builds which astral themselves maintain. I'd say they're pretty trust-worthy.
That's not how trust works. Trust exists as a relationship between two entities. From a security perspective, an entity being "trust-worthy" is meaningless. What matters is whether I trust it or not.
If I install, for example, Debian GNU/Linux, then I'm trusting Debian. I wouldn't expect it to come with a tool that will automatically go and download and run binaries from some other place that I have no knowledge of.
To be clear, it's not a jab at uv as a developer tool. If you're doing dev work then you have to accept the risk. It's about uv being bundled as a system tool such that you can send a script to grandma.
It's a package manager. The job of package managers is to download code that you then run. That certainly has security implications, but that doesn't differentiate uv from pip, Poetry, Cargo, CPAN, npm, RubyGems, ...
Not at the moment, but will your grandma run a script? There is an interesting thing you can already do today for larger applications which is to install uv alongside your app. You can make a curl-to-bash thing or similar that first installs uv into a program specific location to then use that to bootstrap your program. Is it a good idea? I don't know, but you can do that.