Maybe it's just me but when I see Docker with a project like this I already zone out. This is still just based on cdparanoia/cdrdao [0]. I wish people would just push single portable binaries instead of starting the whole process with Docker (especially when the source code is alreaedy available)
0, https://github.com/whipper-team/whipper/blob/develop/whipper...
0, https://github.com/whipper-team/whipper/blob/develop/whipper...
Still not a single binary but as you note with it being written in python and based on cdparanoia, etc how would that work?
It's based on python with relatively obscure requirements[0] that also calls out to system binaries. Looking at the Dockerfile[1] it is built with specific revs of component software to work around various issues. 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.
IMO Docker is one of the "best" and most straightforward ways to package up all of this with the end result (as usual) putting any Linux user two commands away from ripping a disc.
[0] - https://github.com/whipper-team/whipper/blob/develop/require...
[1] - https://github.com/whipper-team/whipper/blob/develop/Dockerf...
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.
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.
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().
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.
For most Docker instances I run I have a simple script (or compose file) which does everything, and by reading it I know exactly which configuration tweaks I did and where the data is stored. No more forgetting that one line in some non-obvious file in /etc that made everything work. Backing it all up is trivial as the volume mapping makes it clear where the important data is stored.
Of course, if the project doesn't have any dependencies and doesn't require tweaking /etc settings to work, then sure a single self-sufficient binary would suffice. However this project relies on Python, so that's probably not gonna work.
It's undeniably useful and pragmatic, but its existence should be a source of shame, a constant reminder that we failed.
As a user/self-administrator, I really do not appreciate a developer throwing a ton of incidental complexity over the wall. Docker is basically a scaling up of the "works on my system" cop out.
I get that there are a lot of oddball distros, but it would seem that a policy of only digging into bug reports on specific well known distros would be more appropriate than basically forgoing the entire concept of a distribution in favor of what are essentially huge static binaries.
It's especially a problem when projects go nuts with this Dockerization anti-pattern, and become actively hostile to distributions shipping plainly administerable versions of their software (looking at you Home Assistant).
I'm sure Docker's great if you want to guarantee that the thing inside can't access the host system, using all kinds of kernel mechanisms, but that's generally the opposite of what you want for application software.
The main advantage of Docker for application distribution that I see is that it's lazy. You don't have to worry about keeping track of what's required, you don't have to fiddle with paths, you just hack until something works and then ship it. That's fine if you prioritize your time over your user's time.
As an example alpine has a smaller default stack size. It’s not obvious if that stack overflow is expected or not.
Or, if building from source is desired for whatever reason, it should be "Clone the repo. Run `cargo build --release` or w/e.
Do you have a specific project in mind that does DVDs?
Snap actually uses the same container technology as Docker.
(Not a fan of Snap, though)