> Install/Restore now are the same operation Finally, I guess. > and all nuget ops are part of the main dotnet CLI which is used by the IDEs and other tooling

> Install/Restore now are the same operation Finally, I guess. > and all nuget ops are part of the main dotnet CLI which is used by the IDEs and other tooling. Okay? I don't really see what the difference is between `nuget foo` and `dotnet nuget foo`. > No plugins needed because everything is consolidated to the same process. Err.. what? > As far as the supply chain, .NET assemblies are IL (intermediate language) and can be inspected and signed to ensure integrity. Sure, and you can disassemble all the x86 binaries on your system, too. But that's not the source code that people are reading or writing, nor is it what's tracked in your Git repository. Even if it's signed, the most you have to go on is "the author promises that this is the same as the corresponding source release". > There are trade-offs but I find it much better than the source-first mess of NPM. This is a fun example, because it NPM is also binary-first and has exactly the same problems! (Except arguably even worse, because your typical package will ship in 3+ different forms, and good luck finding out which one is actually used when). For an actual source-first package manager, take a look at Cargo, Nix, or Cabal. > I don't see how you'd lose knowledge though, you're still building your own source. You're building your own code (for now), but not that of your dependencies. > You can always copy the raw code from an (open-source/decompiled) package into your project and build that way if you really want to. Sure, but you shouldn't have to give up on package management to have a reasonable and trustable build process.