>these people need [their package manager] and [their source code management tool] to deploy? Seriously?

Not really sure I understand what you're implying there

I'm not the poster you're replying to, but I think I understand it.

npm is not just their package management tool... the way most people use it, it depends on someone else's package registry/repository to deploy to your own servers.

And github is someone else's source code management tool/server.

As a matter of policy, if I can't have something on my own server (or one my org controls) I don't get to rely on it to deploy/run my application.

So I think I get the parent's comment... it's a really foreign situation, to me, to depend on the availability of stuff like this on servers I (or my org) don't control in order to deploy my application.

I'm sure the people who depend on these things look at me and say "Wait. You have to set up your own package repository and source control before you can deploy instead of using all this nice stuff that's available in the cloud? Seriously?"

Yeah. I've been on both sides of this coin. If I'm deploying cloud software (which I am, these days), then I have no problem relying on cloud software to make that deployment smoother. But if I ever go back to writing native applications, I sure as hell won't be reliant on the internet in order to manage intranet deployments. These are two different paradigms, and what works well in one doesn't make any sense in the other.

A public package manager and a public source code management tool, both of which are outside of your control. You should be able to deploy from a local [verified and audited] cache of your dependencies.

That's a good goal to strive for, but isn't necessary or practical for everyone. Maintaining local/hosted artifact caches, verifying them, and auditing them is a big hassle, and unless you make something (e.g. fintech, healthtech) that might need such an audit or emergency release, might not be worth the trouble.

Itty bitty company making a social website on a shoestring budget/runway with very few developers? Might just be worth postponing a release a day or two if NPM or GitHub are having issues.

virtualenv makes it trivial. It's not like it's strictly enterprise-grade tech.

How does vrtualenv make maintaining, auditing, and using a local mirror of dependencies trivial? Seems to me I can download a poisoned package into a venv cache just as easily as I can download it with wget, and unless I take the time to check, I’m none the wiser either way.

I was referring specifically to not being able to deploy due to a package manager being down. Of course there are still issues that can crop up with using virtualenv.

I haven’t dug too much, but I believe at my work, we run a server that hosts all our jars, and is the source of truth for all our builds. Nothing that’s been checked in goes straight to the Internet (you can add new dependencies to uncommitted code). And we’re only ~30 devs.

"Wait, you're telling me these people rely on their ISP and the telco infrastructure being operational to deploy? Seriously?"

"Wait, you're telling me these people need an internet-available Ubuntu mirror to install their development environments?"

"Wait, you're telling me these people need their users to have specific, updated browsers in order to run the deployed software?"

"Wait, you're telling me these people need their users to have a patched, up-to-date operating system in order to run your desktop app?"

"Wait, you're telling me these people just assume users won't switch off their computers before saving changes?"

"Wait, you're telling me these people depend on the power grid being available to deploy?"

"Wait, you're telling me these people assume their users have fast, low-latency internet connections to play their real-time multiplayer game?"

You get the idea.

And? Most of these are things you absolutely should be thinking about

"You should be thinking about" and "You need this? Seriously?" are very different statements. Of course you should be aware of dependencies.

And you should also be aware of what it takes to rebuild your stack, and have something in place if that disappears. If you think it's OK to rely on external tools like that to build your system, you deserve all the fallout you get when it fails.