4 ms·

A reminder that interpreters installed with the OS are for the OS, not for you. Plan on installing your own so that you can control versions, libraries, and pa

A reminder that interpreters installed with the OS are for the OS, not for you. Plan on installing your own so that you can control versions, libraries, and packages. (Yes, this post is about "in extremis" dev where you may not be able to do this. Still.)

rini17 2y ago
Nonsense. Bash is for the OS not for you too? Python's standard library covers most scripting use cases, even HTTP networkingand it's stable you can write script and forget. No need to "control" stuff. For example I am using minimal python script + cron for updating letsencrypt certificates in misc linux distros. Everywhere it's system python out of the box without any additional dependencies or virtualenvs.
- xarope 2y ago
  That's why I learned REXX in ye-olde days, because it came installed as default on IBM systems (and not Perl, which was my de-facto prior to). Then python. Nowadays Go(lang). Still trying to decide if it's worth going to Rust for script'ish type work, I have a feeling it's not quite the right choice.
- p_l 2y ago
  Python versioning is BS enough and with enough systems problematic enough that for scripts that have to assume widest range? I torture them with POSIX sh.
- flohofwoe 2y ago
  At least on macOS, Apple strongly discourages depending on the builtin scripting languages, and AFAIK python is no longer preinstalled (instead installing Xcode for the first time will slip a python3.9.x and pip3 into your /usr/bin). Of course you can depend on zsh/bash, but then the Apple UNIX tools are BSD flavoured, not GNU flavoured like on Linux, so Linux shell scripts will also quite often not work out of the box on macOS.
  - rini17 2y ago
    Yes, Apple seems to strongly discourage any kind of scripting which they can not squeeze more money from. But that's not really the same problem.
- deleted 2y ago
  [deleted]
globular-toast 2y ago
Yes and no. In a way a system interpreter is just like a compiler. It's there to enable the user to run programs written in a particular language. The trouble usually starts when a program needs some third party library. So maybe the rule is more like: the system libraries are for the system, not for you. Unless, of course, they are -dev libraries. I do believe modern Ubuntu won't even let users pip install stuff, which should improve things (Gentoo has been configured like this for years).
- guappa 2y ago
  Well you can easily install python3-whatever and use it in a script on debian. What's the problem? pip works fine if used in a venv. They finally blocked installing stuff system wide because it was creating mess. https://xkcd.com/1987/ https://xkcd.com/1987/
  - globular-toast 2y ago
    The post is about out of the box functionality. Requiring a user to also install some system package kinda defeats the purpose here. Plus it's usually not the same version of the library that was expected by the developer of the script. Even used in a venv pip creates a mess as people start creating ad hoc environments and don't really know how to recreate them (cause of many "works for me" type problems). I always advise people to take the extra step of adding a new dependency to pyproject.toml or requirements.txt and then doing `pip install -e .` or `pip install -r requirements.txt`.
    - guappa 2y ago
      > it's usually not the same version of the library that was expected by the developer of the script If the developer of the script is targeting that platform, it is exactly the expected version. Perhaps you should stop using libraries that break API compatibility very often, since it's an indicator of low skill of the authors.

rini17 2y ago

Nonsense. Bash is for the OS not for you too? Python's standard library covers most scripting use cases, even HTTP networkingand it's stable you can write script and forget. No need to "control" stuff. For example I am using minimal python script + cron for updating letsencrypt certificates in misc linux distros. Everywhere it's system python out of the box without any additional dependencies or virtualenvs.

xarope 2y ago
That's why I learned REXX in ye-olde days, because it came installed as default on IBM systems (and not Perl, which was my de-facto prior to). Then python. Nowadays Go(lang). Still trying to decide if it's worth going to Rust for script'ish type work, I have a feeling it's not quite the right choice.
p_l 2y ago
Python versioning is BS enough and with enough systems problematic enough that for scripts that have to assume widest range? I torture them with POSIX sh.
flohofwoe 2y ago
At least on macOS, Apple strongly discourages depending on the builtin scripting languages, and AFAIK python is no longer preinstalled (instead installing Xcode for the first time will slip a python3.9.x and pip3 into your /usr/bin). Of course you can depend on zsh/bash, but then the Apple UNIX tools are BSD flavoured, not GNU flavoured like on Linux, so Linux shell scripts will also quite often not work out of the box on macOS.
- rini17 2y ago
  Yes, Apple seems to strongly discourage any kind of scripting which they can not squeeze more money from. But that's not really the same problem.
deleted 2y ago
[deleted]

globular-toast 2y ago

Yes and no. In a way a system interpreter is just like a compiler. It's there to enable the user to run programs written in a particular language. The trouble usually starts when a program needs some third party library. So maybe the rule is more like: the system libraries are for the system, not for you. Unless, of course, they are -dev libraries. I do believe modern Ubuntu won't even let users pip install stuff, which should improve things (Gentoo has been configured like this for years).

guappa 2y ago
Well you can easily install python3-whatever and use it in a script on debian. What's the problem? pip works fine if used in a venv. They finally blocked installing stuff system wide because it was creating mess. https://xkcd.com/1987/ https://xkcd.com/1987/
- globular-toast 2y ago
  The post is about out of the box functionality. Requiring a user to also install some system package kinda defeats the purpose here. Plus it's usually not the same version of the library that was expected by the developer of the script. Even used in a venv pip creates a mess as people start creating ad hoc environments and don't really know how to recreate them (cause of many "works for me" type problems). I always advise people to take the extra step of adding a new dependency to pyproject.toml or requirements.txt and then doing `pip install -e .` or `pip install -r requirements.txt`.
  - guappa 2y ago
    > it's usually not the same version of the library that was expected by the developer of the script If the developer of the script is targeting that platform, it is exactly the expected version. Perhaps you should stop using libraries that break API compatibility very often, since it's an indicator of low skill of the authors.