There's a ton of package managers, but none that are as built into the platform as nuget is. On top of that, what advantage would there be in having multiple package managers? All you're doing is making the package management harder by splitting it up. How would I indicate my Nuget package depends on a specific version of jQuery?
The line is simple to draw: Nuget should never install anything. It's not chocolatey or aptitude. It provides versioned files, no more. That is its focus, and should remain it, no matter what those files contain.
DLLs are dominant, but definitely not the only type of dependency. Dependencies on text files, javascript, or just about anything else need to be versionable using the same system. If not, you would run into the issues mentioned above.
Multiple projects with different version dependencies might usually be a bad idea, but it's still something you need to support. Unlike some other systems, Nuget can't be opinionated about how you manage your projects. If it was, it would be dropped like a rock by enterprises that don't want to adapt to the package manager of choice. If that makes it harder to do something the platform does for you, nobody really loses.
Package restore is more fragile than local assemblies, yes. We've seen that a few times lately when Nuget was down. These are risks that can be mitigated though, by providing mirrors and a decent local cache.
Putting any sort of binary dependency in a version control system is a problem. They can't be compared to previous versions. Unless you make folders for each version of the package you depend on, you also can't depend on different versions in your projects. And worst of all, if a dev decides to replace a package, it could break something else. Those (and others) are exactly the reasons package managers were created in the first place.
Comments
There's a ton of package managers, but none that are as built into the platform as nuget is. On top of that, what advantage would there be in having multiple package managers? All you're doing is making the package management harder by splitting it up. How would I indicate my Nuget package depends on a specific version of jQuery?
The line is simple to draw: Nuget should never install anything. It's not chocolatey or aptitude. It provides versioned files, no more. That is its focus, and should remain it, no matter what those files contain.
DLLs are dominant, but definitely not the only type of dependency. Dependencies on text files, javascript, or just about anything else need to be versionable using the same system. If not, you would run into the issues mentioned above.
Multiple projects with different version dependencies might usually be a bad idea, but it's still something you need to support. Unlike some other systems, Nuget can't be opinionated about how you manage your projects. If it was, it would be dropped like a rock by enterprises that don't want to adapt to the package manager of choice. If that makes it harder to do something the platform does for you, nobody really loses.
Package restore is more fragile than local assemblies, yes. We've seen that a few times lately when Nuget was down. These are risks that can be mitigated though, by providing mirrors and a decent local cache.
Putting any sort of binary dependency in a version control system is a problem. They can't be compared to previous versions. Unless you make folders for each version of the package you depend on, you also can't depend on different versions in your projects. And worst of all, if a dev decides to replace a package, it could break something else. Those (and others) are exactly the reasons package managers were created in the first place.