8 ms·

Sometimes thrashing is good. Consider the pile of crap that is NuGet in the .NET world. Sure there's Paket, but it has nowhere near the adoption/support of th

Sometimes thrashing is good. Consider the pile of crap that is NuGet in the .NET world. Sure there's Paket, but it has nowhere near the adoption/support of the Microsoft blessed NuGet package manager. At least the Golang team can cherry pick the best ideas & lessons-learned from these community-driven package managers.

mattherman 9y ago
What are some of your specific complaints about NuGet? I've never disliked it that much. For the most part it has "just worked" for me.
- GiorgioG 9y ago
  In large projects, NuGet takes FOREVER to resolve package dependencies - I mean 4+ minutes on a new i7 Thinkpad w/16gb RAM/1TB ssd. Heaven-forbid you want to upgrade a package that exists in all 130 projects in the solution (not my call to have that many projects) - you may as well take a long lunch. I will try to make that the last task of the day so I can let it run for as long as it needs to. The VS UI for NuGet is terribly buggy.
  - pjmlp 9y ago
    Uauu! 4+ minutes. Try to build a C++ or Android project and then go for lunch instead. NuGET is great.
    - GiorgioG 9y ago
      That's 4 minutes to resolve one NuGet package's dependencies - not 4 minutes for a build.
      - pjmlp 9y ago
        Really? I never had it take that long.
        GiorgioG 9y ago
        Usually it doesn't take that long - but it is still generally, unacceptably slow IMO.) Last week I was working on fixing duplicate (version mismatches) package references in the our csproj files) in the branch/solution and I couldn't believe that took 4 minutes to resolve a single reference (after fixing the issue in this particular project!)
        pjmlp 9y ago
        I see, I guess I have been lucky then.
- aljones 9y ago
  When you install a package, nuget will install old dependencies of that package.
- GiorgioG 9y ago
  NuGet / VS has no qualms with having two references to the same package, but different versions in the project file (i.e. Newtonson.Json.dll 9.0 and 10.0) The build will likely fail though and you'll get no visual feedback that there are two refs in the VS NuGet UI. How did we we get in that state to begin with? I suspect through bad project file merges (or possibly NuGet UI bugs, can't say for sure.)
  - flukus 9y ago
    > How did we we get in that state to begin with? I suspect through bad project file merges (or possibly NuGet UI bugs, can't say for sure.) Most likely someone modified the packages for an individual project and not the solution as a whole. Always manage packages at the solution level and your much less likely to have these issues, unless you have multiple solutions...
    - GiorgioG 9y ago
      That sounds great when you have a small team, with 30+ devs it's hard to police.
- wokwokwok 9y ago
  - no local dependencies^ - 'unable to resolve x, arbitrarily picked 1.4.3' - no lock file - nuspec file configuration hell - nuget v2 and v3 feeds arbitrarily going down - installing a specific nuget version on anything other than windows. Basically, it 'just works' for simple senarios, its just not very good for anything else. If you want a comprehensive guide to why its not awesome look at the 'packet' website, they cover the issues quite clearly. ^ you can actually use local dependencies, but its irritating and poorly supported (still uses the global system cache, forcing a cache flush to update).
pdeuchler 9y ago
I've been hearing this argument for about 4 years now. Pointing out that .NET has terrible dependency management does nothing for me when Google's main languages (Python, Java, C++) all have solved dependency management for their own use cases. If the Golang team has had enough time to cherry pick the best ideas and lessons learned to build a language they've had enough time to do so for dependency management. At the very least they could have continued their hard core hands off approach of allowing the community to solve it. But instead they half-assed it and started capriciously anointing chosen solutions and honestly we're probably in a worse spot than we were before dep came along. Plus, lets be honest here, there's no excuse for constantly changing APIs and binaries. If this was truly about getting the best ideas and lessons learned we'd just see refactors of existing tools with slow migrations to new concepts, but instead we've seen multiple complete rewrites, despite multiple efforts to build common libraries that should prevent such events!
- iandanforth 9y ago
  You don't think Python also has thrash? I'm a huge fan of pyenv as it brings in manifest+lockfile+segregated install paths. But those three things are relatively new to Python and very new to get unified.
  - pdeuchler 9y ago
    environment namespacing != dependency management Regardless of your setup at the end of the day you're using pip to solve your dependency graph, and have been for over a decade.
    - iandanforth 9y ago
      I mistyped. I meant pipenv (https://docs.pipenv.org/ https://docs.pipenv.org/) not pyenv. Pipenv does use pip but is a significant, recent upgrade to package management and is now the recommended tool.
- yarrel 9y ago
  Python has several widely-used dependency management systems. C++ has no widely-used dependency management systems. Both languages are doing fine.

mattherman 9y ago

What are some of your specific complaints about NuGet? I've never disliked it that much. For the most part it has "just worked" for me.

GiorgioG 9y ago
In large projects, NuGet takes FOREVER to resolve package dependencies - I mean 4+ minutes on a new i7 Thinkpad w/16gb RAM/1TB ssd. Heaven-forbid you want to upgrade a package that exists in all 130 projects in the solution (not my call to have that many projects) - you may as well take a long lunch. I will try to make that the last task of the day so I can let it run for as long as it needs to. The VS UI for NuGet is terribly buggy.
- pjmlp 9y ago
  Uauu! 4+ minutes. Try to build a C++ or Android project and then go for lunch instead. NuGET is great.
  - GiorgioG 9y ago
    That's 4 minutes to resolve one NuGet package's dependencies - not 4 minutes for a build.
    - pjmlp 9y ago
      Really? I never had it take that long.
      - GiorgioG 9y ago
        Usually it doesn't take that long - but it is still generally, unacceptably slow IMO.) Last week I was working on fixing duplicate (version mismatches) package references in the our csproj files) in the branch/solution and I couldn't believe that took 4 minutes to resolve a single reference (after fixing the issue in this particular project!)
        pjmlp 9y ago
        I see, I guess I have been lucky then.
aljones 9y ago
When you install a package, nuget will install old dependencies of that package.
GiorgioG 9y ago
NuGet / VS has no qualms with having two references to the same package, but different versions in the project file (i.e. Newtonson.Json.dll 9.0 and 10.0) The build will likely fail though and you'll get no visual feedback that there are two refs in the VS NuGet UI. How did we we get in that state to begin with? I suspect through bad project file merges (or possibly NuGet UI bugs, can't say for sure.)
- flukus 9y ago
  > How did we we get in that state to begin with? I suspect through bad project file merges (or possibly NuGet UI bugs, can't say for sure.) Most likely someone modified the packages for an individual project and not the solution as a whole. Always manage packages at the solution level and your much less likely to have these issues, unless you have multiple solutions...
  - GiorgioG 9y ago
    That sounds great when you have a small team, with 30+ devs it's hard to police.
wokwokwok 9y ago
- no local dependencies^ - 'unable to resolve x, arbitrarily picked 1.4.3' - no lock file - nuspec file configuration hell - nuget v2 and v3 feeds arbitrarily going down - installing a specific nuget version on anything other than windows. Basically, it 'just works' for simple senarios, its just not very good for anything else. If you want a comprehensive guide to why its not awesome look at the 'packet' website, they cover the issues quite clearly. ^ you can actually use local dependencies, but its irritating and poorly supported (still uses the global system cache, forcing a cache flush to update).

pdeuchler 9y ago

I've been hearing this argument for about 4 years now. Pointing out that .NET has terrible dependency management does nothing for me when Google's main languages (Python, Java, C++) all have solved dependency management for their own use cases. If the Golang team has had enough time to cherry pick the best ideas and lessons learned to build a language they've had enough time to do so for dependency management. At the very least they could have continued their hard core hands off approach of allowing the community to solve it. But instead they half-assed it and started capriciously anointing chosen solutions and honestly we're probably in a worse spot than we were before dep came along. Plus, lets be honest here, there's no excuse for constantly changing APIs and binaries. If this was truly about getting the best ideas and lessons learned we'd just see refactors of existing tools with slow migrations to new concepts, but instead we've seen multiple complete rewrites, despite multiple efforts to build common libraries that should prevent such events!

iandanforth 9y ago
You don't think Python also has thrash? I'm a huge fan of pyenv as it brings in manifest+lockfile+segregated install paths. But those three things are relatively new to Python and very new to get unified.
- pdeuchler 9y ago
  environment namespacing != dependency management Regardless of your setup at the end of the day you're using pip to solve your dependency graph, and have been for over a decade.
  - iandanforth 9y ago
    I mistyped. I meant pipenv (https://docs.pipenv.org/ https://docs.pipenv.org/) not pyenv. Pipenv does use pip but is a significant, recent upgrade to package management and is now the recommended tool.
yarrel 9y ago
Python has several widely-used dependency management systems. C++ has no widely-used dependency management systems. Both languages are doing fine.