NuGet vs OneGet

446 views
Skip to first unread message

Alex Papadimoulis

unread,
Nov 19, 2014, 10:25:03 AM11/19/14
to nuget-e...@googlegroups.com
So, word has it that Microsoft is throwing some serious resources behind OneGet, the "package manager manager" as they call it. It'll supposedly be built-in to Windows as part of Powershell, and may even be utilized by the update team if there's enough buy-in. I get the feeling they may even get into or replace msi delivery... or maybe that's wishful thinking!

Anywho, it's my understanding that OneGet will be solving the problem of "generalized package management", and abstracting things like archiving, downloafing, discovery, and dependencies. Then there will be managers like PSModule, MSI, NuGet, and so on that sit on top, and will implement protocol and other logic.

Currently, the NuGet support for OneGet is a clusterfuck, mostly because they just forked the code and hacked it till it worked... but obviously that has to change. Or, I seriously hope changes. My *wild ass guess*, at least from managing a team that had to implement NuGet as well, is they will just re-implement the logic from scratch (or keep the fork) instead of trying to incorporate nuget.dll and related libraries.

So what's the plan?

Will NuGet plan to implement the OneGet abstractions, especially client components?

How does one use OneGet in "NuGet" mode? Seems this is useful for build servers (download packages/dependencies), not in Visual Studio (UI, editing .csprojs)?

Is NuGet still aiming for being a "generalized package manager"?  Does this compete with OneGet's goals of being a "package manager manager"?

Is there any cross-team coordination, etc, being planned to mitigate Microsoft's classic "competing teams" problem?


Thanks!

Alex

Jeff Handley

unread,
Nov 20, 2014, 5:43:25 PM11/20/14
to Alex Papadimoulis, nuget-e...@googlegroups.com

Yes, we’re working with the OneGet team, as mentioned here:

http://blog.nuget.org/20141014/in-the-platform.html#nuget-in-new-domains-and-partnerships

 

OneGet can’t really do much with traditional NuGet packages because, as we’ve explained, NuGet relies on the Visual Studio project systems to actually install/uninstall packages.  So just like nuget.exe cannot presently install/uninstall packages in projects, neither can OneGet.

 

Do you have specific feedback here other than it being a “clusterf***”?

--
You received this message because you are subscribed to the Google Groups "NuGet Ecosystem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuget-ecosyst...@googlegroups.com.
To post to this group, send email to nuget-e...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jeff Handley

unread,
Nov 20, 2014, 9:23:31 PM11/20/14
to Alex Papadimoulis, NuGet Ecosystem (google group)

Yes, we very much want to have reusable libraries.  As I’m sure you’ve noticed, the existing NuGet codebase is not amenable to extracting reusable libraries—so we have to build them anew.

 

If you haven’t watched my Oredev sessions yet, I encourage you to do so.  It talks a lot about the engineering work we’ve been doing along the way during NuGet 3.0 and why this stuff isn’t clean yet.

 

Evolving the nuget.org Architecture

·         http://vimeo.com/111285814

 

NuGet 3.0 – Transitioning from OData to JSON-LD

·         http://vimeo.com/111831403

 

 

From: Alex Papadimoulis [mailto:apapad...@inedo.com]
Sent: Thursday, November 20, 2014 4:49 PM
To: Jeff Handley
Subject: RE: [nuget-ecosystem] NuGet vs OneGet

 

Sorry, what I meant by that was, “forking an entire codebase and hacking it until it works in your simple scenario.” In the a real (non-prototype) usage, a library or API re/implementation is appropriate; based on my understanding of the NuGet.dll library, I don’t think it’s usage would be suitable considering all the other stuff they want to do.

 

I don’t have feedback, just those questions I asked. I think you half-answered one (“OneGet in NuGet mode will behave basically like nuget.exe” – cool, thanks), but I’m still not understanding where the product overlaps will be.

 

My motivation for asking this comes as a tools vendor (how many NuGets will we need to support?), and of course as someone who speaks with a whole lot of Microsoft enterprises considering package management.

Alex Papadimoulis

unread,
Nov 21, 2014, 9:07:55 AM11/21/14
to NuGet Ecosystem (google group)

Sweet thanks!

Do you have slides posted anywhere? Not sure if needed, but sometimes easier to condense/share internally here.

Jeff Handley

unread,
Nov 21, 2014, 7:57:08 PM11/21/14
to Alex Papadimoulis, NuGet Ecosystem (google group)

 

 

From: nuget-e...@googlegroups.com [mailto:nuget-e...@googlegroups.com] On Behalf Of Alex Papadimoulis
Sent: Friday, November 21, 2014 6:08 AM
To: NuGet Ecosystem (google group)
Subject: RE: [nuget-ecosystem] NuGet vs OneGet

 

Sweet thanks!

 

Do you have slides posted anywhere? Not sure if needed, but sometimes easier to condense/share internally here.

 

 

From: Jeff Handley [mailto:Jeff.H...@microsoft.com]
Sent: Thursday, November 20, 2014 9:23 PM
To: Alex Papadimoulis
Cc: NuGet Ecosystem (google group)
Subject: RE: [nuget-ecosystem] NuGet vs OneGet

 

Yes, we very much want to have reusable libraries.  As I’m sure you’ve noticed, the existing NuGet codebase is not amenable to extracting reusable libraries—so we have to build them anew.

 

If you haven’t watched my Oredev sessions yet, I encourage you to do so.  It talks a lot about the engineering work we’ve been doing along the way during NuGet 3.0 and why this stuff isn’t clean yet.

 

Evolving the nuget.org Architecture

·         http://vimeo.com/111285814

 

NuGet 3.0 – Transitioning from OData to JSON-LD

·         http://vimeo.com/111831403

 

 

From: Alex Papadimoulis [mailto:apapad...@inedo.com]
Sent: Thursday, November 20, 2014 4:49 PM
To: Jeff Handley
Subject: RE: [nuget-ecosystem] NuGet vs OneGet

 

Sorry, what I meant by that was, “forking an entire codebase and hacking it until it works in your simple scenario.” In the a real (non-prototype) usage, a library or API re/implementation is appropriate; based on my understanding of the NuGet.dll library, I don’t think it’s usage would be suitable considering all the other stuff they want to do.

 

I don’t have feedback, just those questions I asked. I think you half-answered one (“OneGet in NuGet mode will behave basically like nuget.exe” – cool, thanks), but I’m still not understanding where the product overlaps will be.

 

My motivation for asking this comes as a tools vendor (how many NuGets will we need to support?), and of course as someone who speaks with a whole lot of Microsoft enterprises considering package management.

--

Reply all
Reply to author
Forward
0 new messages