Hacker News Reader

Comment by atomicnumber3 | Hacker News Reader

Why does Ruby not have similar problems? (Or if it does, why does nobody seem to care?)

Like why does Ruby have gem and bundler, each doing one thing, whereas python has fifty bazillion tools that all do nearly the same thing if you squint but all have their own weird problems?

I've personally just ended up using poetry and that has mostly stopped me from having to care overmuch about the tooling.

I feel like I'm spoiled coming from Java land, where aside from too much XML, maven just works and if you need to do weird shit (like if you're android, for instance) then you use gradle, which still doesn't fuck up the maven repository format and we can all just live happily. (And nobody uses Ant anymore).

View on HN

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.

I 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.

Python packaging has too many people inventing their own tools and their own little fiefdoms instead of picking one good tool and pushing it forward. There’s also the PyPA, which is an organization (or a group of semi-related volunteers, depending which interpretation suits them best) that maintains many of the tools (although none of the most feature-complete, namely poetry and PDM) and that produces standards that promote tooling proliferation.

I’ve just looked through the docs for poetry and I don’t see anything there about compiled extensions.

The compiled extension story is pretty bad in most tools. Poetry can do it with a custom build.py file, which calls distutils/setuptools: https://stackoverflow.com/questions/60073711/how-to-build-c-...

Not a Ruby guy, but my feeling is that C extensions are more rare in that ecosystem. The majority of the Python woes feel directed at the proper way to package and compile non-Python code.

It is not rare. One of the most popular gems - nokogiri (in the top 10 typically https://rubygems.org/releases/popular) has C extension.

Nokogiri was historically a bit difficult to install but that was because of dependencies and not packaging. To overcome that limitation, nokogiri now has prebuilt binaries for most platforms.

Packaging in ruby using bundler is amazing. It also evolved naturally. In the beginning there was only `gem install`. Then came `bundler` with package list and lock files. It had widespread adoption and now it is shipped with ruby.

Ruby was actually the precursor to the solutions seen nowadays. It was thre first mainstream case of a packaging tool using lockfiles, and one of the persons behind it was also involved in the development of yarn (which brought lockfiles to node) and rust cargo.

Reply on news.ycombinator.com