This phrasing sounds contradictory to me. The whole idea of scripts is that there's nothing to install (besides one standard interpreter). You just run them.
and yet without fail, when I try to run basically any `little-python-script.py`, it needs 14 other packages that aren't installed by default and I either need to install some debian packages or set up a virtual environment.
I'm sure uv can handle this _if_ a given script is packaged "correctly", but most random python scripts aren't - that's the issue we're talking about in this thread.
The whole point of a scripting language IMO is that scripts should _just run_ without me doing a bunch of other crap to get the system into some blessed state. If I need to learn a bunch of python specific things, like "just add _pycache_ to all of your .gitignore files in every directory you might run this script", then it isn't a useful scripting language to me.
I very rarely, if ever, “install” or run other people’s scripts. Because typically, a script is a specialized piece of code that does something specific the user was trying to do when they wrote it.
However, I do often install applications or libraries written by other people in Python. Typically, I don’t have a problem, but sometimes I run into dependency hell. But this is something different than me just writing scripts. For scripting, Python is great.
it's not as portable
pipx can run Python scripts with inline script metadata. pipx is implemented in Python and packaged by Linux distributions, Free/Net/OpenBSD, Homebrew, MacPorts, and Scoop (Windows): https://repology.org/project/pipx/versions.
But a script only has one shebang.
I see it has been proposed: https://discuss.python.org/t/standardized-shebang-for-pep-72....
A lot of people seem to describe a PEP 723 use case where the recipient maybe doesn't even know what Python is (or how to check for a compatible version), but could be instructed to install uv and then copy and run the script. This idea would definitely add friction to that use case. But I think in those cases you really want to package a standalone (using PyInstaller, pex, Briefcase or any of countless other options) anyway.
I was thinking that until I read the forum thread and Stephen Rosen's comments. Now I'm thinking the most useful meta-runner would just try popular runners in order.
I have put up a prototype at https://github.com/dbohdan/python-script-runner.
This notion is still strange to me. Just... incompatible with how I understand the term "script", I guess.
One of my biggest problems with python happens to be caused by the fact that a lot of freecad is written in python, and python3 writes _pycache_ directories everywhere a script executes (which means everywhere, including all over the inside of all my git repos, so I have to add _pycache_ to all the .gitignore ) and the env variable that is supposed to disable that STUPID behavior has no effect because freecad is an appimage and my env variable is not propagating to the environment set up by freecad for itself.
That is me "trying to install other people's scripts" the other people's script is just a little old thing called FreeCAD, no big.
What I don't understand is why you call it a "script".
> and python3 writes _pycache_ directories everywhere a script executes (which means everywhere, including all over the inside of all my git repos, so I have to add _pycache_ to all the .gitignore )
You're expected to do that anyway; it's part of the standard "Python project" .gitignore files offered by many sources (including GitHub).
But you mean that the repo contains plugins that FreeCAD will import? Because otherwise I can't fathom why it's executing .py files that are within your repo.
Anyway, this seems like a very tangential rant. And this is essentially the same thing as Java producing .class files; I can't say I run into a lot of people who are this bothered by it.
A random sh script from 40 years ago usually works or works with only the tiniest adjustment on any current system of any unix-like.
A random py script from 6 months ago has a good chance of not working even on the same system let alone another system of the same platform, let alone another system of a different platform.
Now please next by all means assume that I probably am only complaining about the 2->3 trasition and nothing that actually applies since 15 years ago.
This just isn't true and nothing I have experienced over many years of python programming.
Maybe your problems with python scripts (is it scripts or program?) is an issue with the code?
> I have to add _pycache_ to all the .gitignore
I just add that, once, in my global gitignore.
You could also use shell scripting or Python or another scripting language. While Python is not great at backward compatibility most scripts will have very few issues. Shell scripts are backward compatible as are many other scripting languages are very backward compatible (e.g. TCL) and they areG more likely to be preinstalled. If you are installing Go you could just install uv and use Python.
The article does say "I started this post out mostly trolling" which is part of it, but mostly the motivation would be that you have a strong preference for Go.
bla bla bla
node bla.js
When you know well the language, you dont need to search for this info for basic types, because you remember them.
But that's also true for typed languages.
If you care about anyone but yourself, don't write things in python for other people to distribute, install, integrate, run, live with.
If you don't care about anyone else, enjoy python.