Do we still need NuGet packet manager?

[Korporal]

This is related to: #118

If the Paket visual studio extension provides add/remove then is it safe to stop using (actually remove) the VS addin/extension for NuGet packet management?

If not is it an objective to eventually be able to dispense with it or will there always be a need to still ocassionally depend upon the NuGet package manager?

Thx

[forki]

I didn't use nuget package manager for a long time.

[TeaDrivenDev]

@Korporal I'm skeptical whether it's even possible to uninstall the NuGet extension. I don't think it would be a good idea, either, because you probably can't be sure you'll never encounter projects (open source or otherwise) that don't still use legacy NuGet for dependency management.

[Korporal]

Hi @TeaDrivenDev @forki - I'm still trying to pindown a concrete workflow for my dev team. I need to explain to them exactly how to work with Paket, the tools, menus and scenarios etc. We have many applications, web-services and website some old some new, pretty much all of them use NuGet at both project level and solution level and we frequently encounter subtle build issues and upgrade issues that all hinge in NuGet.

The feeling among my team is that Paket replaces NuGet, yes we must still consume and publish NuGet packages but we only do so in the context of Paket and using Paket tools/commands/extensions. This is what I told them last week anyway.

I don't want to begin upgrading our solutions to use Paket if there are some things it can't do or some things we still need NuGet for etc because we'll just replace on mess with another - I'm hoping to eliminate the painful abstruse issues we get using NuGet.

What we really need - Paket that is - is a complete workflow that includes ALL tools needed to:

1. Upgrade a NuGet based solution 100% to Paket.
2. Upgrade any existing solution that's using NuGet at solution level and/or project level gets upgraded to a solution level Paket solution.
3. Be able to add/remove/upgrade any NuGet package using only Paket tools.
4. Be able create and publish our own NuGet packages using only Paket tools and be able to do so to any NuGet server (public or private).

I've posted several questions here recently (and in the main Paket repo issues) that all stem from these requirements.

It seems to me that there is uncertainty as to whether we can eliminate the NuGet package manager completely or not and I see no support yet for publishing from a purely Paket oriented solution/project.

None of this is a criticism I think the work being done is superb but there's a gap between the low level mechanics of Paket and the real-world day to day workflow needs of developers, you can't assume that every developer is .Net guru or has years of NuGet experience either.

Thx

[forki]

It's hard to answer this. All I can say is: companies with large teams and HUGE solutions work with it. They managed to get their workflow fitting with what the tool provides. But that doesn't necessarily mean your workflow is fitting.

Regarding your points. I think 1) to 3) all belong together and I don't think mixing nuget.exe and paket.exe in one solution makes any sense.

4. can be decided completely indepently. we have many users that use paket as client for nuget packages but nuget.exe with it's nuspec files for package generation. That's a valid approach.

[isaacabraham]

@Korporal Aside from the fact that Paket is an "all or nothing" thing (much like NuGet is I suppose?), all the other items are possible.

1. You can convert an entire solution to Paket using paket update-from-nuget.
2. You can add / remove / upgrade NuGet dependencies from Paket using Paket. Obviously you can't use Paket to modify nuget's .config files etc. - use NuGet for that.
3. You can happily create NuGet packages using Paket. There's documentation on the site to do this as well as examples of it.

I'd be happy to go through these 1 by 1 with you - just not sure what entirely the issues you're facing are :-(

[Korporal]

@isaacabraham, @forki thanks for your posts. Personally I'm disappointed that Microsoft have not devised a rock solid system for this themselves. The core problem - IMHO - is that .Net itself has no concept of "package" only assembly references, it has no concept of "pre release".

NuGet also allows us to create packages that contain more than one assembly, there is no concept for this within .Net or the CLR - only assembly references.

The CLR loads assemblies, nothing else (forget about 'modules' for now), .Net assemblies (in their manifest) have references only to assemblies not packages.

By introducing a "package" concept one is - in a sense - trying to extend the CLR but artificially and this is the problem.

I don't want to deal with these artificial abstractions unless they've been designed right into .Net itself and have proven robustness.

Think about an ideal world, I'd only ever add assembly references, period. In Visual Studio I can add a reference (which I know is purely compile time) to an assembly in a variety of ways, but not a package - no I must step outside if this world into an artificial one and use some other tool or command. Even though - when all's said and done - an assembly is all that it boils down to, I must fiddle with a different paradigm.

I think it would be far better to dispense with the concept of a "package" and stick simply with assemblies, assemblies work, they're solidly defined within .Net, at the end of the day there are only assemblies so why pretend otherwise?

The only thing we should focus on is the fact that some assemblies are going to be remote, somewhere on the network but other than that they are just assemblies and we should strive to avoid treating remote assemblies differently to local assemblies.

I know we need to add abstractions and adjust our paradigm but I do think it would be better overall if we did so without replacing or hiding the well defined concept of assembly references.