2 ms·
In some ways, it's actually pretty weird that Ruby hasn't had similar problems (I say wearing both my Ruby fanboy and Python packaging contributor hats). In ot
by woodruffw 4y ago
In some ways, it's actually pretty weird that Ruby hasn't had similar problems (I say wearing both my Ruby fanboy and Python packaging contributor hats).
In others, it's less weird: Ruby's upswing happened with Rails and a handful of other "killer" frameworks, which helped to solidify developer workflows (and expectations) around packaging. Python, by contrast, has had multiple generations of "killer" usecases, each with their own baggage (and many predating any real packaging standards).
The history of Python packaging is also much older, and much more devolved than anybody in 2023 would consider reasonable for a packaging ecosystem: the earliest generation of PyPI, for example, was just an index that pointed to other webhosts for downloads, rather than a full package host. This helped ossify manual workflows that developers at the time were content with, and some of that cost is still being paid forwards.
- aragilar 4y agoI think the main reason Ruby has avoided this (like most other newer languages) is the lack of a numeric/scientific ecosystem, which is where the real mess begins. Science code never dies (because the rewrite almost never implements everything the predecessor had, so now you need both the original tool and its "replacement"), so I have tools built from Fortran, C, C++, Tcl, Java, Python and now Rust to combine.