4 ms·

It sounds like you're talking about outdated experiences (on topic with the article). Install/Restore now are the same operation, and all nuget ops are part of

It sounds like you're talking about outdated experiences (on topic with the article). Install/Restore now are the same operation, and all nuget ops are part of the main dotnet CLI which is used by the IDEs and other tooling. No plugins needed because everything is consolidated to the same process. As far as the supply chain, .NET assemblies are IL (intermediate language) and can be inspected and signed to ensure integrity. There are trade-offs but I find it much better than the source-first mess of NPM. Go is interesting but only recently got official module approach and still relies on convoluted path-based references. I don't see how you'd lose knowledge though, you're still building your own source. 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.

metaltyphoon 5y ago
Its almost as if people forget that git submodule is a thing, if they want the source from the packages
- Smaug123 5y ago
  Git submodules are indeed a thing, and they're even supported by the `git` CLI, but I'm not sure I would go so far as to say that they're a first-class feature of Git :P
Nullabillity 5y ago
> 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.
- hackerfromthefu 5y ago
  I like where you're coming from, but .NET also supports an ecosystem of commercial developers who sell commercial closed source libraries, as well as open source. I also had some issues with Nuget, but fair to say that's been the case with pretty much every package manager I've used. Re trustable build process, some of the .NET team has been blogging about reproducible builds in the last year.

metaltyphoon 5y ago

Its almost as if people forget that git submodule is a thing, if they want the source from the packages

Smaug123 5y ago
Git submodules are indeed a thing, and they're even supported by the `git` CLI, but I'm not sure I would go so far as to say that they're a first-class feature of Git :P

Nullabillity 5y ago

> 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.

hackerfromthefu 5y ago
I like where you're coming from, but .NET also supports an ecosystem of commercial developers who sell commercial closed source libraries, as well as open source. I also had some issues with Nuget, but fair to say that's been the case with pretty much every package manager I've used. Re trustable build process, some of the .NET team has been blogging about reproducible builds in the last year.