4 ms·

Just yesterday I was working on a monitoring agent that was a python script deployed through gitlab-ci, and executed inside a docker container through logstash.

Just yesterday I was working on a monitoring agent that was a python script deployed through gitlab-ci, and executed inside a docker container through logstash. I bet you could do the same with about 5 lines of shell (wget|grep|curl -XPOST). It would be simpler, easier to modify, and it wouldn't ever break. Shell scripts aren't necessarily messy or complex.

kragen 3y ago
python is a particularly bad choice for things that are not supposed to break; the python maintainers have adopted a new policy of intentionally breaking new things every release. recent casualties include asyncore, distutils, and imp https://docs.python.org/3/whatsnew/3.12.html#removed https://docs.python.org/3/whatsnew/3.12.html#removed there are people who foolishly depend on python for things that need to work. i hope that at some point they band together behind a fork that doesn't pull this kind of nonsense, but for the time being, that hasn't happened. if you wrote stuff in python in 01995 or 02000 or 02005 it probably still worked in 02015, but today, basically no python from before 02015 works
- icedchai 3y ago
  Perhaps don't upgrade your Python willy-nilly? That seems like a sane solution to this problem.
  - kragen 3y ago
    debian stable no longer has python 2. debian's pypy package has its own fork of cpython 2 in order to be able to build itself. numerous other projects are doing similar things debian's versioning system for packages doesn't really contemplate needing to install old versions of a package because the maintainers are deliberately breaking new versions of it, so in 'bookworm' debian 12.5, the only cpython available to install is python 3.11. so if you want to 'not upgrade python' you are going to have to take on the maintenance burden of the old versions yourself; debian isn't going to help some other package managers handle this kind of situation better (nix is notably excellent at it) but that doesn't really help with the maintenance burden of keeping up with security fixes
    - icedchai 3y ago
      My "willy-nilly" comment meant "don't upgrade it without planning in advance" not "don't upgrade it, period." Part of that planning can be choosing to stay on an older LTS distro until you have time to properly migrate your code to a Python released in this decade.
      - kragen 3y ago
        or you could just write the code in the first place in a language that doesn't have maintainers that intentionally break old code. that's what you would do if you aspire to write code that constitutes part of the intellectual heritage of humanity, as opposed to being an expedient way to resolve a problem you have this week, to be thrown away in a month or two. you can still compile c code that uses gets(), you know. a couple of years ago i fixed a perl cgi script i'd written in 01998 to work with current perl; it took me half an hour. and euclid's proofs are still valid 2500 years after he wrote them down
        icedchai 3y ago
        C is a very slow moving language, but platform-specific APIs (meaning outside of stdlib) change more frequently. "C" does not exist in isolation, and outside of toy applications, not useful without the underlying platform APIs. If you were migrating C code, from say, Mac OS 7, or even Mac OS X 10.1, you would have to make many, many changes. If you're migrating code across Unix platforms (say, 1990's SunOS to modern Linux), you'll require changes, too.
        kragen 3y ago
        sure, but the gratuitous breakage i'm complaining about in python is inside of stdlib, and even in the language syntax itself. and i've frequently taken c code from 1990s sunos and compiled it on modern linux, and yes, it's true that it usually requires a few changes where it interacts with the outside world—but only a few it's true that very small programs are often little more than glue between the underlying platform apis, but large programs tend to have a much lower surface-to-volume ratio. that's why τεχ still runs, virtually unchanged since 01990, and you can easily render plain τεχ documents from the 80s or 90s with τεχ today—even with pdfτεχ

kragen 3y ago

python is a particularly bad choice for things that are not supposed to break; the python maintainers have adopted a new policy of intentionally breaking new things every release. recent casualties include asyncore, distutils, and imp https://docs.python.org/3/whatsnew/3.12.html#removed https://docs.python.org/3/whatsnew/3.12.html#removed there are people who foolishly depend on python for things that need to work. i hope that at some point they band together behind a fork that doesn't pull this kind of nonsense, but for the time being, that hasn't happened. if you wrote stuff in python in 01995 or 02000 or 02005 it probably still worked in 02015, but today, basically no python from before 02015 works

icedchai 3y ago
Perhaps don't upgrade your Python willy-nilly? That seems like a sane solution to this problem.
- kragen 3y ago
  debian stable no longer has python 2. debian's pypy package has its own fork of cpython 2 in order to be able to build itself. numerous other projects are doing similar things debian's versioning system for packages doesn't really contemplate needing to install old versions of a package because the maintainers are deliberately breaking new versions of it, so in 'bookworm' debian 12.5, the only cpython available to install is python 3.11. so if you want to 'not upgrade python' you are going to have to take on the maintenance burden of the old versions yourself; debian isn't going to help some other package managers handle this kind of situation better (nix is notably excellent at it) but that doesn't really help with the maintenance burden of keeping up with security fixes
  - icedchai 3y ago
    My "willy-nilly" comment meant "don't upgrade it without planning in advance" not "don't upgrade it, period." Part of that planning can be choosing to stay on an older LTS distro until you have time to properly migrate your code to a Python released in this decade.
    - kragen 3y ago
      or you could just write the code in the first place in a language that doesn't have maintainers that intentionally break old code. that's what you would do if you aspire to write code that constitutes part of the intellectual heritage of humanity, as opposed to being an expedient way to resolve a problem you have this week, to be thrown away in a month or two. you can still compile c code that uses gets(), you know. a couple of years ago i fixed a perl cgi script i'd written in 01998 to work with current perl; it took me half an hour. and euclid's proofs are still valid 2500 years after he wrote them down
      - icedchai 3y ago
        C is a very slow moving language, but platform-specific APIs (meaning outside of stdlib) change more frequently. "C" does not exist in isolation, and outside of toy applications, not useful without the underlying platform APIs. If you were migrating C code, from say, Mac OS 7, or even Mac OS X 10.1, you would have to make many, many changes. If you're migrating code across Unix platforms (say, 1990's SunOS to modern Linux), you'll require changes, too.
        kragen 3y ago
        sure, but the gratuitous breakage i'm complaining about in python is inside of stdlib, and even in the language syntax itself. and i've frequently taken c code from 1990s sunos and compiled it on modern linux, and yes, it's true that it usually requires a few changes where it interacts with the outside world—but only a few it's true that very small programs are often little more than glue between the underlying platform apis, but large programs tend to have a much lower surface-to-volume ratio. that's why τεχ still runs, virtually unchanged since 01990, and you can easily render plain τεχ documents from the 80s or 90s with τεχ today—even with pdfτεχ