| You make a good point -- these problems exist everywhere. It's a trade-off between flexibility and restrictions/constraints. Some platforms manage this balance better than others. The other issue is that many of us don't notice certain roadblocks because we're so used to working around them. In your case, my first instinct would be to `install.package(package_name)` and if something breaks, I google the error. Usually within 3-4 steps I'm on my way. But if something has just been released and no one's hit issues yet, google might not turn up anything. So then I'd have to open an issue on their github page and wait. CRAN generally does a good job curating -- it has strict policies like if a package submission doesn't pass tests and doesn't succeed on automated builds on x number of platforms, it doesn't make it to the repo. That said, I've experienced a few package breakages before so I also want to validate your experience. While I'm here, I also want to say as a Linux person, I hate the "compile first" culture of UNIX based software -- I'm not sure where it originated, probably GNU and open-source? Sometimes I just want to install a library and have it work -- just give me static binaries, don't make me compile stuff. I really don't care about the source code. To me as an end user, the appeal of open-source is that the source is available if I want it, but most of the time I really don't. I get really frustrated when some Python packages don't offer wheels, and when the compilation breaks I have to spend hours/day figuring out what went wrong. TensorFlow 1 was particularly bad -- even with Bazel, things would break between releases. It's a huge productivity suck. |