I am sympathetic to Drew's view that packages require establishing a longer term trust relationships. That's literally what is happening when you use someone's

I am sympathetic to Drew's view that packages require establishing a longer term trust relationships. That's literally what is happening when you use someone's package. You are trusting them. So, I want the situation to change.However, there are some problems I see: 1. Developers are used to using their language of choice's solution for virtual environments (ex. go modules, node_modules, python venv, etc) 2. Instead of 1 relationship with the language package manager, you need N (where N is each platform you "officially" support) 3. Younger/newer packages aren't in native package managers yet. 4. Different apps want to use conflicting versions of libraries For #1, VM's/Vagrant and Docker are a good answer. But many dev's only know their language's ecosystem and don't know shell well enough. Personally, I think every dev needs to know their system well enough to be able to manage their environment and do things on the shell. But after working with more juniors, this is going to be a huge stumbling block. For #2 seems unavoidable unless someone automates submitting to a bunch of package managers. And worse, many package managers do a lot of patching. Again I'm sympathetic to patches b/c many devs have a lot of bad practices. But this is a huge problem for devs, because it bogs down support channels with bugs tedious to track down and reproduce. There's a kind of catch 22 in younger packages too, where they aren't in the repo's so no-one uses them. But no-one uses them, so it's not worth the effort to get into the repos. For #4, this seems to be the perennial static vs. dynamic linking debate. Where newer languages and systems seem to be falling on the static side. TL;DR: I live native package managers but there's too many problems to ignore. Until the dev experience is better, people are going to continue using language package managers.