4 ms·

> "Nuget package management is abysmal" Why? Explain more. > "legacy reliance on XML" What reliance? Are you talking about .csproj files? They're very minima

> "Nuget package management is abysmal" Why? Explain more. > "legacy reliance on XML" What reliance? Are you talking about .csproj files? They're very minimal now. XML vs JSON is an old discussion: both are trivial to deal with when small but get unwieldy as they grow (however XML has much better structural support). Also the .NET configuration system reads from JSON files by default.

Nullabillity 5y ago
> Why? Explain more. - Why do some packages behave differently depending on whether they were installed from an install or restore command? This shouldn't have any observable difference, sync (restore) should be the only operation that touches the package cache at all. - Opaque reliance on invisible plugin hooks. Back when I had to use it, it was pretty common to get told "oh, just add this random dependency" to fix whatever weird behaviour NuGet got up to that time. Why or how did it fix it? Nobody really seemed to know. - Binary package managers suck. They make your supply chain more vulnerable, and they are an additional repository to set up and manage. And they tend to lead to losing the knowledge of how to do a full source rebuild at all.
- manigandham 5y ago
  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.

Nullabillity 5y ago

> Why? Explain more. - Why do some packages behave differently depending on whether they were installed from an install or restore command? This shouldn't have any observable difference, sync (restore) should be the only operation that touches the package cache at all. - Opaque reliance on invisible plugin hooks. Back when I had to use it, it was pretty common to get told "oh, just add this random dependency" to fix whatever weird behaviour NuGet got up to that time. Why or how did it fix it? Nobody really seemed to know. - Binary package managers suck. They make your supply chain more vulnerable, and they are an additional repository to set up and manage. And they tend to lead to losing the knowledge of how to do a full source rebuild at all.

manigandham 5y ago
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.