For one, it's used to install all kinds of crap (like jQuery) and sometimes has all too tight dependency on Visual Studio in its .ps1 scripts.
Next, all the mess with having assemblies for different versions of .NET Framework inside single nupkg -- I want to see the person who decided this will be a good idea.
Third, why include version numbers in directory names? To make it harder to update dependencies?
Fourth, dependencies. "[1.3.2,1.5)" - how cool is this?
Fifth, the whole "Package Restore" concept is flawed.
Why would installing something like jQuery be a bad fit for Nuget? It's a dependency like any other, just because it's in JS doesn't mean you shouldn't handle it the same way you would other packages.
Versions in directory names make sense if you've got multiple projects depending on different versions of the same package. Upgrading everything at once isn't always an option.
Could you elaborate why package restore is flawed? And do you have an alternative that doesn't involve putting all your dependencies in source control?
Because there's a ton of package managers for JavaScript and NuGet is reinventing the wheel here, squared. Granted, very few (if any) of them work on Windows, but that's outside the scope here.
And even if we accept that it's OK for NuGet to install JS dependencies, where do we draw the line? Install Bootstrap with NuGet? FontAwesome? Should NuGet execute SQL scripts while installing Elmah? Install MSI packages as part of "install-package"?
All in all, DLLs are the most dominant type of dependencies for .NET and NuGet should laser-focus on those.
As for multiple projects within the same solution depending on different versions of packages, that's asking for trouble. And again, why default to the illogical behavior of including version numbers in directory names when this is only justified in like 0.1% of cases?
Package Restore is _very_ fragile, both in terms "what happens if NuGet server is down" and in terms of "Visual Studio has gone mad and does weird shit trying to restore packages".
And I saw you using "source control" implying that the only thing to belong there are text-only source files. What if we call it "version control"? This will magically allow us to put all the binary dependencies and live a happy life. Cheers!
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
NuGet itself leaves a lot to be desired.
For one, it's used to install all kinds of crap (like jQuery) and sometimes has all too tight dependency on Visual Studio in its .ps1 scripts.
Next, all the mess with having assemblies for different versions of .NET Framework inside single nupkg -- I want to see the person who decided this will be a good idea.
Third, why include version numbers in directory names? To make it harder to update dependencies?
Fourth, dependencies. "[1.3.2,1.5)" - how cool is this?
Fifth, the whole "Package Restore" concept is flawed.
Why would installing something like jQuery be a bad fit for Nuget? It's a dependency like any other, just because it's in JS doesn't mean you shouldn't handle it the same way you would other packages.
Versions in directory names make sense if you've got multiple projects depending on different versions of the same package. Upgrading everything at once isn't always an option.
Could you elaborate why package restore is flawed? And do you have an alternative that doesn't involve putting all your dependencies in source control?
Because there's a ton of package managers for JavaScript and NuGet is reinventing the wheel here, squared. Granted, very few (if any) of them work on Windows, but that's outside the scope here.
And even if we accept that it's OK for NuGet to install JS dependencies, where do we draw the line? Install Bootstrap with NuGet? FontAwesome? Should NuGet execute SQL scripts while installing Elmah? Install MSI packages as part of "install-package"?
All in all, DLLs are the most dominant type of dependencies for .NET and NuGet should laser-focus on those.
As for multiple projects within the same solution depending on different versions of packages, that's asking for trouble. And again, why default to the illogical behavior of including version numbers in directory names when this is only justified in like 0.1% of cases?
Package Restore is _very_ fragile, both in terms "what happens if NuGet server is down" and in terms of "Visual Studio has gone mad and does weird shit trying to restore packages".
And I saw you using "source control" implying that the only thing to belong there are text-only source files. What if we call it "version control"? This will magically allow us to put all the binary dependencies and live a happy life. Cheers!
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.