3 ms·

I would certainly go with ignorant. I stay away from Windows and, in consequence, from .NET. I've heard about NuGet, but I haven't used it, so I don't know if i

by dozzie 9y ago

I would certainly go with ignorant. I stay away from Windows and, in consequence, from .NET. I've heard about NuGet, but I haven't used it, so I don't know if it is any good. On the other hand, I've seen both strategies (large and small packages) in use, and the better dependency resolution mechanisms and package building tools, the better small packages work. I don't need to install plethora of GNOME and Python packages, I just run `apt-get install exaile' and have it installed. From programmer's perspective this works equally well; I may want to include some specific part of Boost library, but I can also run `apt-get install liboost-all-dev' and be done, and leave detecting the actual dependencies to package builder's tooling.

SideburnsOfDoom 9y ago
> I would certainly go with ignorant. I stay away from Windows and, in consequence, from .NET. Right, so what specifically are you adding to today's discussion? What drew you to it?
- dozzie 9y ago
  You claimed that "there is no one right answer" to distributing code (or so I understood), which is false, because it works well in the world outside Windows.
  - SideburnsOfDoom 9y ago
    What specifically would you change about Nuget?
  - HannibalChew 9y ago
    It has nothing to do with Windows.
lazulicurio 9y ago
NuGet is okay, in my opinion. My two biggest issues with it aren't actually issues with NuGet, but with the surrounding ecosystem. First is that MSBuild hard-codes references, so building a multi-targeted project with references to a multi-targeted NuGet package is a nightmare. From what I've read in the documentation, Paket (an alternative package manager) is supposed to be designed to help with this, but it was already enough of a struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual Studio. Second is the fragmentation of the .NET frameworks, a la this article. Combined with how .NET makes native interop fairly easy (i.e. platform dependent packages), you get either bloated monolith packages or a proliferation of satellite packages. Other than that, I've had a fairly easy and straightforward time with NuGet. But then again, I've never seen a project with more than a dozen or so dependencies, compared to using Maven in Java where you pull in dependencies like hotcakes. I'm split. I'd love to see the churn settle down so the surrounding ecosystem can mature. On the other hand, there are definite pain points with the existing tooling. I remember seeing declarative package references as a feature request for Roslyn, which would be absolutely wonderful, but even if it's released fairly soon, it's probably going to take years for adoption to spread.
- dozzie 9y ago
  > Second is the fragmentation of the .NET frameworks [...] [you get monoliths] or a proliferation of satellite packages. And I don't see why "proliferation of satellite packages" is supposed to be bad. It works in Debian's APT, including development packages. Maybe somehow NuGet is not okay, after all? Certainly something is different between the two.
- khellang 9y ago
  > First is that MSBuild hard-codes references, so building a multi-targeted project with references to a multi-targeted NuGet package is a nightmare. From what I've read in the documentation, Paket (an alternative package manager) is supposed to be designed to help with this, but it was already enough of a struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual Studio. This has changed radically with Visual Studio 2017 and the newer MSBuild tooling. See https://github.com/khellang/Scrutor/blob/master/src/Scrutor/Scrutor.csproj#L7 https://github.com/khellang/Scrutor/blob/master/src/Scrutor/... for an example. It has three targets with both conditional and common package references.

by dozzie 9y ago

SideburnsOfDoom 9y ago

> I would certainly go with ignorant. I stay away from Windows and, in consequence, from .NET. Right, so what specifically are you adding to today's discussion? What drew you to it?

dozzie 9y ago
You claimed that "there is no one right answer" to distributing code (or so I understood), which is false, because it works well in the world outside Windows.
- SideburnsOfDoom 9y ago
  What specifically would you change about Nuget?
- HannibalChew 9y ago
  It has nothing to do with Windows.

lazulicurio 9y ago

NuGet is okay, in my opinion. My two biggest issues with it aren't actually issues with NuGet, but with the surrounding ecosystem. First is that MSBuild hard-codes references, so building a multi-targeted project with references to a multi-targeted NuGet package is a nightmare. From what I've read in the documentation, Paket (an alternative package manager) is supposed to be designed to help with this, but it was already enough of a struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual Studio. Second is the fragmentation of the .NET frameworks, a la this article. Combined with how .NET makes native interop fairly easy (i.e. platform dependent packages), you get either bloated monolith packages or a proliferation of satellite packages. Other than that, I've had a fairly easy and straightforward time with NuGet. But then again, I've never seen a project with more than a dozen or so dependencies, compared to using Maven in Java where you pull in dependencies like hotcakes. I'm split. I'd love to see the churn settle down so the surrounding ecosystem can mature. On the other hand, there are definite pain points with the existing tooling. I remember seeing declarative package references as a feature request for Roslyn, which would be absolutely wonderful, but even if it's released fairly soon, it's probably going to take years for adoption to spread.

dozzie 9y ago
> Second is the fragmentation of the .NET frameworks [...] [you get monoliths] or a proliferation of satellite packages. And I don't see why "proliferation of satellite packages" is supposed to be bad. It works in Debian's APT, including development packages. Maybe somehow NuGet is not okay, after all? Certainly something is different between the two.
khellang 9y ago
> First is that MSBuild hard-codes references, so building a multi-targeted project with references to a multi-targeted NuGet package is a nightmare. From what I've read in the documentation, Paket (an alternative package manager) is supposed to be designed to help with this, but it was already enough of a struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual Studio. This has changed radically with Visual Studio 2017 and the newer MSBuild tooling. See https://github.com/khellang/Scrutor/blob/master/src/Scrutor/Scrutor.csproj#L7 https://github.com/khellang/Scrutor/blob/master/src/Scrutor/... for an example. It has three targets with both conditional and common package references.