Oh this looks amazing! I had pretty much stopped using Python for my one-off scripts because of the hassle of dependencies. I can't wait to try this out.
I've played with it for a while now, and for one off scripts where python might make more sense than bash, e.g., I write the script this way with uv, and then I only need uv and the script.
One of the complaints about python is that a script stops working over time (because the python installation changes with os updates), and this kinda sorta doesn't make it go away entirely, but what it does do is to eliminate a bunch of the hassle to getting things to work.
No, because with golang you can drop the binary in an empty docker container and you're done -- you never have to recompile it or worry about your pypi mirror disappearing. If you're deploying a python script with uv, it needs some kind of internet connection.
Am I crazy for having my default interactive shell "/bin/env python" point to a virtual environment with all the random dependencies that my one off scripts need, so I can just run "python oneoneoff.py"? All of my one off scripts combined use maybe a dozen dependencies. If I need more, I just install them there. I use pyenv, so it's trivial to change the version of python that the interactive shell uses (default or temporary within the current shell).
From my perspective, people seem to make it difficult to use python, more from not understanding the difference between interactive shell and non-interactive shell configurations (if you think the above breaks system tools that use python, then you don't understand the difference, nor that system tools use /bin/python rather than /usr/env python), with a bit of cargo-cult mixed in, more than anything.
What would you do if some of the deps started to have conflicts in them? Also, what are your plans for migration when you'll need to move from one os version to another?
Implicit solutions like yours have lower cost of entrance, but larger cost of support. uv python scripts just work if you set them up once
Note that the context here is specifically one off scripts.
> Also, what are your plans for migration when you'll need to move from one os version to another?
None of my one off python code is OS dependent. But, none of my professional production code is either, because it's rare to have OS specific python code (unless you're building your own libraries), so this concern is very confusing to me. But, to make sure I can reproduce my one off environment, I periodically pip freeze a requirements.txt.
