None of this is different in any other language, including C. If you run a C app that uses outside libraries, or a Python app that uses outside libraries, or anything else, you either devote well more than a week out of every year to updating libraries, or everything is super old and frozen and impossible to change, or everything risks breaking when you upgrade your OS distribution (or other source of packages). That's how production software works.
If you want to claim that the state-of-the-art in every single environment isn't production-ready, you're using the term "production-ready" in a very different way from its common meaning.
Can you present an ecosystem that does this better? All I've heard you claim is that Node is bad, in ways that are not specific to Node.
> None of this is different in any other language, including C.
Really? Because NPM is the only dependency system I know of that doesn't verify packages in any way.
> If you run a C app that uses outside libraries, or a Python app that uses outside libraries, or anything else, you either devote well more than a week out of every year to updating libraries, or everything is super old and frozen and impossible to change, or everything risks breaking when you upgrade your OS distribution (or other source of packages).
This hasn't been my experience. Unlike the Node community, the C community tends to feel strongly about reverse compatibility. The Python community has become a bit more diluted in recent years, but as long as you stick with mature libraries, upgrades are usually no more than updating some version numbers in the `requirements.txt` and running `pip install -r`. In cases where Python packages break dependencies, they're usually pretty decent about giving deprecation warnings.
In NPM, mature libraries break backwards compatibility without warning all the time, sometimes without even a version number change (by virtue of the dependency's dependencies).
Can you point me to an example of a mature library in Python breaking like Babel did when left-pad happened?
> Can you present an ecosystem that does this better? All I've heard you claim is that Node is bad, in ways that are not specific to Node.
The ways I mentioned are absolutely specific to Node.
> Really? Because NPM is the only dependency system I know of that doesn't verify packages in any way.
npm verifies the SSL cert on its connection to the registry. pip does the same thing. Neither verifies signatures on the packages, or anything else.
Both of which are better than C build scripts that involve downloading tarballs from SourceForge and running `make install`.
> This hasn't been my experience.
Then you're not running C in production, sorry. Or you're ignoring the friendly build engineers and distro packagers (like myself) who spend their days solving these issues so you don't have to notice. Which is great, we solve these problems so you don't have to, but you really need to defer to the people with expertise.
> Can you point me to an example of a mature library in Python breaking like Babel did when left-pad happened?
Sure. Babel didn't break when left-pad happened. A certain way of installing Babel did. I have no idea how you keep conflating a method of installing packages (that isn't even what serious production users use) with code. So, "all of them."
I can give you countless examples of mature libraries and software packages in C, Python, or many other languages where `./build.sh` or equivalent, that wgets some crap from SourceForge, stopped working in the same way. But if you're doing `./build.sh` as part of your regular production workflow, you know that it's going to break and that you have better options.
> Both of which are better than C build scripts that involve downloading tarballs from SourceForge and running `make install`.
True, but I thought you were the one who wanted to limit our conversation to competent installations?
> Sure. Babel didn't break when left-pad happened. A certain way of installing Babel did. I have no idea how you keep conflating a method of installing packages (that isn't even what serious production users use) with code. So, "all of them."
Really? So how do you install Babel the first time in order to shrinkwrap it?
> I can give you countless examples of mature libraries and software packages in C, Python, or many other languages where `./build.sh` or equivalent, that wgets some crap from SourceForge, stopped working in the same way.
I'm not sure what this has to do with anything. Yes, you may sign your uploads. Nobody verifies them on download.
Since you seem to be a fan of Google, try Googling 'pip signature verification' and reading the results. Here's one place to start: https://github.com/pypa/twine/issues/157
> Really? So how do you install Babel the first time in order to shrinkwrap it?
The same way you install anything else from any other ecosystem? The packages have to be up and online when you initially retrieve them, yes. I have no idea how you think that's NPM-specific. If you would like to download some code, you have to have somewhere to download it from.
If you want to claim that the state-of-the-art in every single environment isn't production-ready, you're using the term "production-ready" in a very different way from its common meaning.
Can you present an ecosystem that does this better? All I've heard you claim is that Node is bad, in ways that are not specific to Node.