3 ms·

I love scripting in Python too. I just hate trying to install other people’s scripts.

by mr_toad 10mo ago

flanked-evergl 10mo ago
If they use https://packaging.python.org/en/latest/specifications/inline-script-metadata/ https://packaging.python.org/en/latest/specifications/inline... then it becomes a breeze to run with uv. Not even a thing.
- hu3 10mo ago
  but then you need uv it's not as portable
  - networked 10mo ago
    Inline script metadata itself is not tied to uv because it's a Python standard. I think the association between the two comes from people discovering ISM through uv and from their simultaneous rise. 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 https://repology.org/project/pipx/versions.
    - zahlman 10mo ago
      Yes, many things can use inline script metadata. But a script only has one shebang.
      - networked 10mo ago
        Perhaps a case for standardizing on an executable name like `python-script-runner` that will invoke uv, pipx, etc. as available and preferred by the user. Scripts with inline metadata can put it in the shebang line. I see it has been proposed: https://discuss.python.org/t/standardized-shebang-for-pep-723-script-runner/87736 https://discuss.python.org/t/standardized-shebang-for-pep-72....
        zahlman 10mo ago
        I get the impression that others didn't really understand your / the OP's idea there. You mean that the user should locally configure the machine to ensure that the standardized name points at something that can solve the problem, and then accepts the quirks of that choice, yes? 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.
        networked 10mo ago
        > You mean that the user should locally configure the machine to ensure that the standardized name points at something that can solve the problem, and then accepts the quirks of that choice, yes? 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 https://github.com/dbohdan/python-script-runner.
        zahlman 10mo ago
        Neat. Of course it doesn't have much value unless it's accepted as a standard and ships with Python ;) But I agree with your reasoning. Might be worth reviving that thread to talk about it.
zahlman 10mo ago
> I just hate trying to install other people’s scripts. This notion is still strange to me. Just... incompatible with how I understand the term "script", I guess.
- Brian_K_White 10mo ago
  You don't understand the concept of people running software written by other people? 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.
  - zahlman 10mo ago
    > 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.
    - fastasucan 10mo ago
      This is 99% of the complaints in these threads. "I had this very specific problem and I refuse to handle it by using best practise, and I have not used python to anything else, but I have very strong opinions".
enriquto 10mo ago
> hate trying to install other people’s scripts. 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.
- lucb1e 10mo ago
  By that logic, you don't install an OS, you just put the bootloader and other supporting files on your storage medium of choice and run it
- solid_fuel 10mo ago
  > The whole idea of scripts is that there's nothing to install 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.
  - fastasucan 10mo ago
    Its up to the programmer whether they use external packages or not. I dont ser the problem with setting up a venv, but if this is packaged correctly you could do uv run.
    - solid_fuel 10mo ago
      You're hand waving away the core problem - if I'm running someone else's script, it's not up to me if they used external packages or not, and in python using someone else's script that relies on external packages is a pain in the ass because it either leaves setting up a venv and dealing with python's shortcomings up to me, or I have to juggle system packages. 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.
flufluflufluffy 10mo ago
Anytime I have the need to write a script, I write it myself. When I do this, I like to do it in Python, rather than Go. 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.

I love scripting in Python too. I just hate trying to install other people’s scripts.

by mr_toad 10mo ago

I love scripting in Python too. I just hate trying to install other people’s scripts.

If they use https://packaging.python.org/en/latest/specifications/inline-script-metadata/ https://packaging.python.org/en/latest/specifications/inline... then it becomes a breeze to run with uv. Not even a thing.

hu3 10mo ago
but then you need uv it's not as portable
- networked 10mo ago
  Inline script metadata itself is not tied to uv because it's a Python standard. I think the association between the two comes from people discovering ISM through uv and from their simultaneous rise. 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 https://repology.org/project/pipx/versions.
  - zahlman 10mo ago
    Yes, many things can use inline script metadata. But a script only has one shebang.
    - networked 10mo ago
      Perhaps a case for standardizing on an executable name like `python-script-runner` that will invoke uv, pipx, etc. as available and preferred by the user. Scripts with inline metadata can put it in the shebang line. I see it has been proposed: https://discuss.python.org/t/standardized-shebang-for-pep-723-script-runner/87736 https://discuss.python.org/t/standardized-shebang-for-pep-72....
      - zahlman 10mo ago
        I get the impression that others didn't really understand your / the OP's idea there. You mean that the user should locally configure the machine to ensure that the standardized name points at something that can solve the problem, and then accepts the quirks of that choice, yes? 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.
        networked 10mo ago
        > You mean that the user should locally configure the machine to ensure that the standardized name points at something that can solve the problem, and then accepts the quirks of that choice, yes? 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 https://github.com/dbohdan/python-script-runner.
        zahlman 10mo ago
        Neat. Of course it doesn't have much value unless it's accepted as a standard and ships with Python ;) But I agree with your reasoning. Might be worth reviving that thread to talk about it.

zahlman 10mo ago

> I just hate trying to install other people’s scripts. This notion is still strange to me. Just... incompatible with how I understand the term "script", I guess.

Brian_K_White 10mo ago
You don't understand the concept of people running software written by other people? 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.
- zahlman 10mo ago
  > 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.
  - fastasucan 10mo ago
    This is 99% of the complaints in these threads. "I had this very specific problem and I refuse to handle it by using best practise, and I have not used python to anything else, but I have very strong opinions".

enriquto 10mo ago

> hate trying to install other people’s scripts. 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.

lucb1e 10mo ago
By that logic, you don't install an OS, you just put the bootloader and other supporting files on your storage medium of choice and run it
solid_fuel 10mo ago
> The whole idea of scripts is that there's nothing to install 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.
- fastasucan 10mo ago
  Its up to the programmer whether they use external packages or not. I dont ser the problem with setting up a venv, but if this is packaged correctly you could do uv run.
  - solid_fuel 10mo ago
    You're hand waving away the core problem - if I'm running someone else's script, it's not up to me if they used external packages or not, and in python using someone else's script that relies on external packages is a pain in the ass because it either leaves setting up a venv and dealing with python's shortcomings up to me, or I have to juggle system packages. 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.

flufluflufluffy 10mo ago

Anytime I have the need to write a script, I write it myself. When I do this, I like to do it in Python, rather than Go. 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.