1. 21
  1. 7

    As an Arch Linux packager I can sympathize with the Gentoo folks here. It’s been quite frustrating to have working solutions deprecated before working replacements are in place.

    1. 9

      Honestly, this xkcd is the perfect summary of the entire Python ecosystem. Since that comic was authored, the situation has only got more complicated.

      1. 5

        Every time I’ve actually talked to someone who claimed to be fighting with that, their story inevitably led back to “well, first I looked at the single standard default tooling, and decided against using it”.

        (yes, there is a simple default stack of packaging tools: setuptools as the builder, pip as the installer, venv as the managed/isolated environment. They work well and do their tasks. No, I don’t know why people seem to go to nearly any lengths and unimaginable levels of pain and frustration to try to avoid them)

        1. 2

          The “standard” tooling changes extremely often in the Python ecosystem. Distutils, setuptools, PEP-517 (and even this is ridiculously fragmented with flit, poetry and a whole bunch of other options). None of it is “standard” by any means. There is also no clear migration path for each of these methods, and most Python projects really don’t care.

          1. 1

            The “standard” tooling changes extremely often in the Python ecosystem. Distutils, setuptools, PEP-517 (and even this is ridiculously fragmented with flit, poetry and a whole bunch of other options). None of it is “standard” by any means.

            I don’t really know where this idea comes from.

            Well, actually, I do, and I said so above: pip is 13 years old, setuptools is 17 years old, virtualenv is 14 years old (and the venv module containing its core functionality has been in the Python standard library for 9 years). The problem isn’t “Python” or lack of a “standard”. Those are the standard tools. They’ve been around for ages, they’re battle-tested, they do their jobs extremely well, and their end-user interfaces evolve extremely slowly (when they evolve at all). I’ve been writing pip install for literally over a decade at this point!

            And that’s it. That’s the whole thing. People seem to get in this vicious loop where for whatever reason they utterly refuse to even look at the core standard tooling and then go cobble together their own monstrosity out of baling twine and duct tape, and then blame Python or “Python packaging” for the resulting problems.

        2. 3

          I honestly assumed you were linking to XKCD 927 but figured I’d click through for the laugh anyway. I had no idea there was a Python specific variant.

      2. 4

        Python is a huge mess. The entire time wasted on porting 2 to 3 and maintaining the messes would’ve better just been spent on porting Python software to better languages. Go and Rust are given here, but several others come to mind as well (Julia, Ada, etc.). I’m not a big Rust fan, but Python really takes the cake here and has wasted me personally a lot of time as well.

        Using Gentoo myself, I always felt a bit uneasy considering the fact that my package manager is just running on an interpreter that could easily get shot or broken for some reason (which can happen in the case of Python if one simple environment variable is set incorrectly or a single supplementary file missing).

        If they used Go, C or Ada (now that would be really cool!), they could statically link the critical programs and would also be more independent from the mess that the Python ecosystem is. However, I do understand they already have limited developer-time and other things to focus on, which sadly is fewer and fewer actual software updates and more and more “infrastructure” things and webshit-bloat infesting infrastructure that should not change every 1-2 years.

        1. 1

          Synth and the Ravenports admin tool are written in Ada.

        2. 2

          Having spent a lot of time doing corporate internal tooling with Python, all I can say is that it is something that I would advise against. The standard I look to see met for internal tooling at is a static binary of some sort. Go, Rust, and others provide that facility.