What is OneGet?
OneGet a unified package management interface component with a set of managed and native APIs, a set of PowerShell cmdlets, and a WMI provider. The component accepts both Microsoft-provided and 3rd party-provided plugins which extend the functionality for a
given package type.
What is in the CTP Release of OneGet?
The current prototype consists of:
- OneGet Core – Provides the unified interface for software discovery, installation and inventory (SDII). Handles the loading and multiplexing of plugins and provides isolation for them. Exposes APIs for package management plugins to access common
features. Defines a set of APIs that host applications should implement when consuming the library.
- OneGet PowerShell Module– implements a set of PowerShell cmdlets that give users access to the functionality of the OneGet Core.
- Prototype Chocolatey Plugin– a prototype plugin for the OneGet Core module that implements a Chocolatey-compatible package manager. This is a from-scratch implementation of the Chocolatey client, and doesn’t share code with the original.
Why didn’t you just use the current version of Chocolatey?
The original Chocolatey project was built as a set of PowerShell functions wrapped up with batch files, and wasn’t built in such a way that could be easily or efficiently adapted to working in the OneGet plugin architecture.
Our prototype implementation of Chocolatey is written from scratch in C#, and offers much tighter integration with OneGet, than would be possible if we just wrapped the existing Chocolatey. This greater degree of integration offers performance benefits, as
well as the future ability to expose the functionality via managed and native APIs, along with manageability via WMI. This also gives us the opportunity to deliver security and service improvements to Chocolatey as we proceed.
We're going to work with the Chocolatey project to have one single chocolatey plugin that meets everyone's needs :
see Rob's post
Aren't there security concerns around using Chocolatey scripts?
The current implementations of Chocolatey has a tight, small-community built up around them, and packages are published by those involved in the community. Certainly it currently has a lot of implicit trust of the package publishers, and as such, could easily
be subverted for nefarious purposes. Our goal is to work with the community to drive the design and implementation of Chocolatey and drastically improve the security and verifiability of Chocolatey packages so that consumers are protected from malware.
What package managers are supported?
Today, just Chocolatey. We will certainly be working on more in the future.
Can I build my own package manager plugin?
Very Soon! Plugins can be written in .NET or PowerShell modules, and shortly after the CTP, we should be prototyping the native bindings which would permit plugins written in any language that can build a .DLL. Wrapping of existing package managers can easily
be done by writing a script in PowerShell, and is probably the simplest short-term solution for existing systems.
How will users get my package manager plugin?
Part of our work with the community is to develop a central hub for plugins that can be dynamically discovered and installed so that they don't have to ship them in-box. Policies will permit consumers to decide which plugins they allow and for what purposes.
Whats' the difference between Chocolatey and OneGet ?
OneGet is designed to be a package-management-manager. It will expose a plugin APIs for third-party package management systems to plug into it, as well as APIs for applications to access diverse package-management systems without having to code for each one.
Chocolatey (the original) does support multiple package types (cygwin, ruby, etc), but isn't designed to support WMI, PowerShell, Native and Managed APIs.
a (new) prototype implementation of the Chocolatey package manager.
OneGet should also be shipping with PowerShell, which means that eventually, it should be in-box in future versions of Windows.