"Why is the JavaScript ecosystem like this?" is a very similar complaint, where containers are again the dead-easy obvious answer (to almost everything, Mysql vs MariaDB difficulty remains).

Making stuff work together isnt always easy. Having a predictable easy to manage unit can be really nice, offload the particular ecosystem concerns & get folks to "just use it" places.

https://news.ycombinator.com/item?id=34250969

Yea, OP's complaint is valid, but this was the wrong project to post it on because this particular project actually does come with distro packages and source. Providing a Docker image as an option is great. Providing it as the only option, not so great.

> Still not a single binary but as you note with it being written in python and based on cdparanoia, etc how would that work?

Cosmopolitan python is a good starting point: https://ahgamut.github.io/2021/07/13/ape-python/

> IMO Docker is one of the "best" and most straightforward ways to package up all of this

No. Using containers has its place. But would you use containers on hello world?

Likewise, if you've got to use a container for cd ripping tool, you've failed somewhere.

The post you're replying to gave several reasons why something like Cosmopolitan Python is not sufficient.

This is nothing like hello world.

> This is nothing like hello world.

Full disagree. Ripping a CD in 2023 should be as complicated as hello world.

> The post you're replying to gave several reasons

Let's go through them!

> Packages are available for just about any distro

I use windows.

> It's based on python with relatively obscure requirements

So include the modules along with the cosmopolitan python

> that also calls out to system binaries

Put that logic into the cosmopolitan binary: if Linux then do this, if Windows then do that etc

> Take a look at the build docs and you'll see just how many existing projects (python and otherwise) it takes to deliver the end result.

Do the same to these extra projects.

> most straightforward way

The lazy way? Yes.

Like if you can't be bothered to implement basic features, have a billion dependencies. If as a consequence you code is unstable, put it into a container, and orchestrate.

Here's a simple C equivalent: if you have memory leaks because you know malloc() but don't know about free(), the right solution isn't to kill and respawn when you go above some memory quota, but to learn about free().

It's only for Linux and they make that absolutely clear. If you use Windows there are plenty of other options referenced in this thread and elsewhere.

This project is at least nine years old with over 1,600 commits. There are 105 open issues.

If you bothered to spend a few minutes to look at the source and open issues you'd realize how complicated and difficult it actually is to enable as many (Linux) users as possible (with cheap, out of spec, and shoddy hardware) to make close-to-perfect rips (with metadata, in multiple formats, etc) of nearly any compact disc produced over the last four decades.

Finally, as someone who has created and contributed to open source projects calling this project "lazy" is downright offensive and completely unfair. Please feel free to spend your personal time and effort to create something better. I'm sure the people who successfully use whipper everyday will be anxiously awaiting and rejoice at the release of your perfect implementation.

Then, when it (never) appears someone like you will be here trashing a design decision or compromise you made. Or, as the saying goes, I'm sure the maintainers of the project would appreciate your pull requests.

Valid criticism and debate is great (and beneficial) but your comment and attitude go way too far.

Please try to put yourself in the shoes of people who donate their time to actually produce something of value and utility (for free) only to have keyboard warriors come out of the woodwork and call them lazy.