3 ms·

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

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

Kwpolska 4y ago
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.
- wiredfool 4y ago
  I’ve just looked through the docs for poetry and I don’t see anything there about compiled extensions.
  - Kwpolska 4y ago
    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-extensions-via-poetry https://stackoverflow.com/questions/60073711/how-to-build-c-...
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 ago
  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.
deleted 4y ago
[deleted]
mrtweetyhack 4y ago
[dead]
0cf8612b2e1e 4y ago
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.
- boundlessdreamz 4y ago
  It is not rare. One of the most popular gems - nokogiri (in the top 10 typically https://rubygems.org/releases/popular 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.
chucke 4y ago
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.

Kwpolska 4y ago

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.

wiredfool 4y ago
I’ve just looked through the docs for poetry and I don’t see anything there about compiled extensions.
- Kwpolska 4y ago
  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-extensions-via-poetry https://stackoverflow.com/questions/60073711/how-to-build-c-...

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

deleted 4y ago

[deleted]

mrtweetyhack 4y ago

[dead]

0cf8612b2e1e 4y ago

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.

boundlessdreamz 4y ago
It is not rare. One of the most popular gems - nokogiri (in the top 10 typically https://rubygems.org/releases/popular 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.

chucke 4y ago

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.