Most of the time, Python's biggest issue isn't performance, it's the nightmare of trying to distribute it. If you want to merely run a python program you need to be educated in "python DevOps", or you'll get people gasping and saying "FFS, why don't you just create an env and activate it and pip install to it then make your own flipping shortcut to a script that activates that env and runs your code, you moron, Jeeeeeesus."
Uv and PEP-723 style inline dependency declarations has been great at $DAYJOB. It's made a bunch of our standalone scripts trivial to distribute to non-software engineers.
I'm also bullish on using them with Marimo notebooks as a replacement for Jupyter notebooks.
that the "activate it" part gets any airtime really pisses me off. that has all to do with bash and zero to do with python. the "activate" script should never have seen the light of day.
include a bin/run-python wrapper script in your project, and have that set environment variables and call the .venv/bin/python binary. done.
yes, i realise in replying to this comment i'm admitting that i'm part of the problem exactly described, but the "activate" script has caused more confusion in the long run than is worthwhile and the "running from a .venv/" directory could have been a much smaller problem instead of the wind-tunnel it has become.
Yes, it should have been something like a flatpak, snap, Appimage or some other horrible thing. But I can see why a developer would just want to set a few vars, because you need to do that in a shell anyway to pip install some other requirement or debug on the command line. There is no polish, no user story.
From the perspective of a user who just wants to install and use something, it doesn't matter why python is atrocious, it just is. Ideally, something like pipx would be far far better than it is, and bundled by default with the system python. Every venv should get added to a launcher that gives access to a shell, an IDE or any python program in the venv. In fact if the python venv module was just a teensy bit better it could (optionally, but by default) do this for you.
That is obviously not what I meant by "solving it with bash" and well you know it.
First, one often needs to set PYTHONPATH etc, and this is best done near the point of execution, in a wrapper script and not wangling around in ~/.bash_profile where it gets forgotten, and is not project-specific.
Secondly, and more importantly, your suggestion assumes the venv lives in a fixed location. This is unlikely to be the case.[1] What is preferable is something which is independent of filesystem location. The bin/run-python script is able to find its location on the filesystem, and the location of the venv relative to it.
[1] You might have a custom python distribution with a bunch of modules installed into a well-known location and therefore using that for the python in your application is a reasonable solution, but that is not what we are talking about here.
Comments
Most of the time, Python's biggest issue isn't performance, it's the nightmare of trying to distribute it. If you want to merely run a python program you need to be educated in "python DevOps", or you'll get people gasping and saying "FFS, why don't you just create an env and activate it and pip install to it then make your own flipping shortcut to a script that activates that env and runs your code, you moron, Jeeeeeesus."
PEP-723 solves this nicely.
https://peps.python.org/pep-0723/
https://news.ycombinator.com/item?id=43500124
Uv and PEP-723 style inline dependency declarations has been great at $DAYJOB. It's made a bunch of our standalone scripts trivial to distribute to non-software engineers.
I'm also bullish on using them with Marimo notebooks as a replacement for Jupyter notebooks.
that the "activate it" part gets any airtime really pisses me off. that has all to do with bash and zero to do with python. the "activate" script should never have seen the light of day.
include a bin/run-python wrapper script in your project, and have that set environment variables and call the .venv/bin/python binary. done.
yes, i realise in replying to this comment i'm admitting that i'm part of the problem exactly described, but the "activate" script has caused more confusion in the long run than is worthwhile and the "running from a .venv/" directory could have been a much smaller problem instead of the wind-tunnel it has become.
Yes, it should have been something like a flatpak, snap, Appimage or some other horrible thing. But I can see why a developer would just want to set a few vars, because you need to do that in a shell anyway to pip install some other requirement or debug on the command line. There is no polish, no user story.
From the perspective of a user who just wants to install and use something, it doesn't matter why python is atrocious, it just is. Ideally, something like pipx would be far far better than it is, and bundled by default with the system python. Every venv should get added to a launcher that gives access to a shell, an IDE or any python program in the venv. In fact if the python venv module was just a teensy bit better it could (optionally, but by default) do this for you.
why not solve it with bash then, just put
#!/path/to/your/venv/bin/python
as first the line of your script, done/done
That is obviously not what I meant by "solving it with bash" and well you know it.
First, one often needs to set PYTHONPATH etc, and this is best done near the point of execution, in a wrapper script and not wangling around in ~/.bash_profile where it gets forgotten, and is not project-specific.
Secondly, and more importantly, your suggestion assumes the venv lives in a fixed location. This is unlikely to be the case.[1] What is preferable is something which is independent of filesystem location. The bin/run-python script is able to find its location on the filesystem, and the location of the venv relative to it.
[1] You might have a custom python distribution with a bunch of modules installed into a well-known location and therefore using that for the python in your application is a reasonable solution, but that is not what we are talking about here.
Hopefully PEP-723 and uv will alleviate this.
Docker took that job