Comment by ungovernableCat
2 days ago
Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?
Indeed. I've heard a lot of words about how trivially easy vibe coding makes building software, and how just about anyone can build something in no time at all anymore. Even stuff about how people will vibe code one-off private software for everything at all times, and such.
There really shouldn't be a reason for vibe coders to complain about any software decisions. Vibe coding a personal fork you better agree with should be a piece of cake. Isn't that part of the vibe code promise?
What's more is yt-dlp already has plugin support for 3rd party interpreters. They're just saying they don't want to deal with supporting bun themselves and the infrastructure for anyone else do use whatever they want is already there.
This is just the standard misguided entitlement people feel towards other people's projects supported by other people's time and effort. It's continually outrageous to me how people feel they can just volunteer other people's time and effort to support their own wants. The people who do the work are entitled to make their decisions and if you don't like it fork it yourself. This has been the way of this ecosystem since it started.
yt-dlp is surprisingly hackable as is.
Because for a lot of AI fans (not all, I know), it's like a religion. They aren't content to live and let live and let history show whose approach to building software is better, they insist that everyone has to agree with them. I have that situation at my job and it drives me insane that honest technical disagreement isn't allowed when it comes to AI.
I speculate that I could indeed "vibe code" a better JS build integration because what they have does not make sense at a first look.
It appears they mixed JS building into their python project, aiming to support multiple package managers which are executed from their python script.
This explains the otherwise non-sensical explanation about bun < v2 ignoring the lockfile: they use a separate lockfile for each package manager. They did not check in one for bun v1, which they claimed to support, consequently it is not using a lockfile.
That's not how JS packaging normally works. I would set up a separate folder for the JS project, and use one package manager to build the project, like anyone else does.
Publish the package to npm, or bundle the tarball with your python program.
I guess the permission model of the JS runtime could be another topic, but at least they would have their build fixed without worrying about Node dependency resolution and package managers in their Python code.