(cross posted from Garrett's MSDN Blog)

I've found myself answering the same questions over-and-over, so rather than continue to do this piecemeal, I figured it's about time to just post this stuff once.

Hopefully you'll find it enlightening, or at least entertaining :)

1. OneGet is not a package manager.

Ah, off with a bang, eh?

Ok, so it's like this—OneGet isn't technically a Package-Manager, it's more of a Package-Manager-Manager. Its actual purpose is to bring together a diverse set of installers, package services, and inventory schemes under a set of unified APIs and PowerShell cmdlets.  Rather than having end-users understand the complexity and diversity behind each package manager, this allows users to simple consume packages in a common way.  Individual package management systems plug into OneGet by implementing a package provider. At the moment, providers can be written in either PowerShell or in any .NET language (ie, C#, VB, F# etc…).

And yeah, it's true, not all package management systems behave the same, and it's really difficult to set down such a set of common patterns that could possibly apply to every package manager. We've opted to take the simple route, and mandate very little to how a package manager implements its own business, and the provider can implement as little of the interface as makes sense. For example, we have one provider (the “Programs” provider) that simply reports the inventory of the items stored in the ARP (Add/Remove Programs table). At the bare minimum, a OneGet package manager provider basically needs to be able to refer to ‘packages’ by a “name”, and possibly a “version” (the format of both is entirely up to the developer).

Of course, we have some ideas and guidelines that kinda lay out how you should implement a given feature, but I wouldn’t consider them terribly strict.

2. OneGet is not another implementation of Chocolatey

Ok, this one’s kinda my fault.

A smidgen over 12 months ago when we released the initial prototype of OneGet at //Build 2014, I wrote a proof-of-concept Chocolatey provider to go along with it (mainly as a test of the interface itself, and a ‘template’ of what a package manager needs to do). On top of that, for quite some time it was the only package provider available for OneGet.

And then everyone jumped on the “OneGet is a Chocolatey-compatible package manager” story.  Sorry about that.

To be clear, my implementation of the Chocolatey provider is neither complete nor up to date, and will be removed from OneGet in the very near future. There are community people working on the official Chocolatey provider, and when that’s ready, OneGet should be able to bootstrap and install that provider dynamically so that users can access it at that time.

The really good news is that there are actually a number of providers in development—some by us, some by 3^rd parties—that will be available in the very near future and will bring the features of many more package management systems into OneGet. You can check out the list of things that people have suggested or are planning on the Github issues page.

3. OneGet is not for installing PowerShell modules either.

Hmm. I’ve seen some posts and articles that hint at this. Or more than hint at it, outright express it.

Indeed, there is a OneGet package provider called “PowerShellGet” that is a package manager for installing PowerShell modules, from a common gallery. This provider was developed at the same time as OneGet, is fundamental to PowerShell going forward, and is included with OneGet. PowerShellGet can be accessed by the standard set of OneGet cmdlets, as well as thru its own cmdlets (i.e., Find-Module, Install-Module, etc.)

4. Heck, OneGet does not install software.

Well, not directly and certainly not on its own.

OneGet delegates all installation operations to the installed package provider plugins.  Yes, we do include a very minimal set of package providers along with OneGet—basically the bare minimum of what we need to discover and install more providers. This minimum set includes:

-          An MSI provider (installs Windows Installer .MSI files). This provider does not at this time support remote feeds, just simply implements the minimum features to install MSI files that the user has acquired.

-          An MSU provider (for installing Microsoft Update files). Again, a very minimal installer that just handles MSU files that the user has downloaded.

-          A Programs provider—which doesn’t even install programs, but merely exposes the inventory of the Add/Remove Programs application in Windows. It has some minimal support to allow uninstalling some software.

-          A Bootstrap provider—a custom provider which can download and install new Package Providers dynamically from a feed on the internet.  This is how you will be able to get more providers without having to manually download them.

-          The aforementioned PowerShellGet provider—for installing PowerShell modules.

5. OneGet is not meant to replace existing infrastructure or technologies.

When I started the OneGet project, I wanted to make it very clear that we’re not trying to shut down existing package installers or technologies, and replace it with “The-One-True-Package-Manager-Which-Will-Replace-All-Others”—far from it. There are what, about 20 billion pieces of software available for Windows today, made over the course of the last 20-some years. It would be a bit foolish to assume that anyone would be able to—or willing to—repackage all of that software to fit a common universal package format.

Diversity is a wonderful thing, and should be celebrated, not condemned—especially in software installation.  I think that experts in Python are far more capable of determining the correct behavior for installing Python modules, and the idea that I or anyone else outside of that community would be able to lay down a smarter format, is completely senseless. The same goes for Node.js, Perl, PHP, Ruby, etc.

What I can do, is provide a means to bring it all together so that disparate package managers can work together in a common way, rather than stepping on each other’s expertise.

6. OneGet does not have a repository. Well, maybe one.

This is an easy one, right?

Since OneGet isn’t a package manager, it doesn’t have package repositories. Although, we do have the Bootstrap provider, and it does have one—but there isn’t a “OneGet Repository Server”. So when people ask ‘How do I setup a OneGet repository’, the answer is … “you can’t”.

Of course that’s a bit pedantic, since the implied question is “How do I set up a Repository that OneGet can see for ‘Chocolatey’ packages” since that’s one of the most visible providers that can be used with the prelease versions of OneGet today. The answer for that is: Chocolatey is based on NuGet, and so you have to set up a NuGet server. You can also check out 3^rd party options like ProGet or MyGet which are really much simpler to deal with.

However, since there are a lot more package manager providers just around the corner, I wouldn’t rush out and start laying down new infrastructure for hosting your packages and installers, because it’s certainly possible that new providers can simply use what you have available today, without having to explicitly setup something new.  And if you have some sort of repository and service, well perhaps you might be able to put together a provider that brings all that together.

7. OneGet does not solve all installation woes.

I’ve seen a lot of chatter that “OneGet is going to solve problem XYZ” and questions like “how will it problem ABC go away?”

Really, it’s not going to do that overnight. I did write a post that talks about some of the fundamental things that we should all be thinking about when installing software, and while that’s basically been my compass when building OneGet, we’ve got a long way to go to making software installation smooth.

OneGet does have the benefit that it sets the stage for how well-behaved package management systems should work, and the more package management system that work with it, should drive better results for everyone.  If you have ideas or questions about how we can make this a reality, I wholehearted recommend that you come lend your voice to making OneGet better, by participating in the OneGet project on Github.

8. OneGet is not just for Windows 10.

Ever since its inception, OneGet has been designed in such a way that its core should work with .NET 4.0, and the PowerShell cmdlets need only at least PowerShell v3 (WMF3). This makes it so that for general use it can work find on Windows 7/ Windows Server 2008 R2 and beyond. Now, certain provider may not be able to run on certain versions of Windows – for example, a provider that relies on some Windows 10 technology (like the app store?) won’t work on Windows 7. That’s just common sense.

We’re also looking at getting it to run on some of the special versions of Windows too, like Windows Nano Server, and I’d really like to see what I can do for that version of Windows 10 that runs on Raspberry PI. At this point, I haven’t nailed down when, but remember, OneGet is open source software, and others can do some work with it as well.

I haven’t talked much about it lately, but one of my other goals with OneGet is to port it to non-Windows operating systems too. Sure, you’ve already got RPM and DPKG (i.e., apt-get) on Linux, but does RPM install packages from Node.js?  How about installing Python modules? A universal package management layer could be useful for bringing together package installation on a variety of systems. Since OneGet isn’t a package manager, and it’s not designed to displace actual package managers, it’s not a completely crazy idea to bring it to Linux.

9. OneGet is not finished.

My pappy always used to say that “A journey of a thousand miles begins with shoeing a horse”… Well, we’re still writing the basic features for OneGet, and I can foresee a really long road yet ahead.

I think that as we go on, we’re going to be adding more and more features into OneGet, adding more providers, and seeing its use integrated into more than just the PowerShell cmdlets—GUIs, more tools, etc… where do you think it should be integrated into?

10. OneGet isn't called OneGet. 

And, finally we get to the weird one. We renamed the “OneGet” PowerShell module to “PackageManagement” a while back.

I keep telling folks, it’s not that we changed the name, we just changed the spelling. :)

The open source project is still called OneGet, and I will continue to call it OneGet. 

So, why did we rename the module? Well, working in a very large multinational company, you always have those guys around whose job it is to make sure things are on the level with regards to things like trademarks. Especially when you ship a feature in Windows. I don’t know if y’all realize this, but Windows is a big deal to a lot of folks around these parts.

Anyway, when there is the potential for ambiguity in some country somewhere, these go-getters can run off and make it all work out. The trouble is that do to so can be a smidgen pricey, and before they go do their thing, they’ll ask you if the name is terribly important, and if using a more generic term might make it so they don’t have to do that.

And the answer in this case is… yeah, we could change the spelling to “PackageManagement”, I’m not going to fret about exactly what the module is named. We can still have the open source project hosted at http://oneget.org so it’s not a really big deal.

I hope that clears up some of the outstanding questions, and I’m sure it likely spawns a few more, so if y’all have more questions, bring ‘em and we’ll see if we can’t answer them for you.

Garrett Serack (@fearthecowboy)

(cross-posing this from Garrett's MSDN Blog)

I started thinking about how all of this fits together and how we (as an ecosystem) need to be able to work together, and — more importantly — still allow different systems to work how they please.

Many years ago, Kim Cameron came up with a list of 7 Laws of Identity. They outline some core fundamental principles that any Identity system should follow to ensure that everyone's (users, identity providers, and relying parties) security is maximized.

It occurred to me that concepts from the Laws could be recycled in a way that reflects how we can define the general parameters for an installation ecosystem.

Users must always be able to make the ultimate decisions about their system, and installers must never do unauthorized actions without the user's consent. Essentially, we really want to ensure that changes that the user doesn't want aren't being applied to their systems. This means that an installer should always provide a clear and accurate description of the product being installed, and ensure that the user is in control of their systems. User interfaces or tools that obscure or break this trust with the user should be avoided. Ideally, user interfaces should strive for some amount of minimalism, instead of serving up a collection of pedantic screens which users tediously press 'Next' through. Less UI means that users are far more likely to pay attention to what is said.

Personal opinion: I guess at the same time, I should point out a particular gripe of mine, especially with open source software installation on Windows. The proliferation of EULAs and Licenses masquerading as EULAs in the installation process should stop. Many OSS licenses don't actually have any requirement for the end user to agree to the terms of them before installation, so please stop asking for people to 'agree' just to make it look like you have a 'professional' installer.

If you actually have a requirement to record an acceptance of license, perhaps you should be doing that upon first use (or whatever activity actually requires the acceptance of the license).

Changes to a system should aim to offer the least amount of disruption to the system. Installing unnecessary or unwanted components adds to bloat, and will increase the potential attack surface for malware.

Personal opinion: There is a category of software out there that has opted to provide their software free, but heavily — and often with great vigilance — attempts to install toolbars, add-ons, or other pieces of trash software that serve only to funnel advertising to the user. Others nag the user to change their default search settings or their browser home page for similar purposes. These behaviors are abusive to customers, and should be avoided at all costs.

The ecosystem should easily support many different technologies. There is no one-size-fits-all answer. Software comes in all shapes and sizes. Any well-behaved individual packaging or installation technology should be welcome to participate. Choosing one technology over another should be left to the publisher. Pushing this to the logical ends means that any attempt to unify these should permit and encourage use of any part of the ecosystem.

Installation technologies should never obfuscate what is being done, and should never place the system in a state that cannot be undone. Again, keeping in mind that the target system belongs to the user, not the publisher, end users should be able to expect that uninstallation should succeed without issue or require any additional work to clean up.

Personal opinion: On a slightly tangential note, I'd like to talk about rebooting the system. Windows Installers seem to be over-eager to reboot the OS, either on installation or uninstallation. Now, there is a very small class of software that can actually justify having to reboot the system. But 99%+ of software should be able to deal with file conflicts, proper setup, managing their running processes or services, manipulating locked files, removing temporary files, and all of those other reasons that you think you need to reboot the system in order to finish the work. If you need help on doing this, ask. You'll be doing everyone a great service.

Ideally, a given package should be able to install into different installation scopes (OS/Global scope, Restricted/User scope, and Local/Sandboxed scope) and support installation into online and offline (VM Images) systems. Packaging systems should consider how they can help products to be fully installed in these scopes.

Software installers on Windows have, since time began, been conflating configuration with installation. This approach introduces several painful problems into the software installation process:

• It increases the amount of UI during installation, which only leads to additional confusion for the end user.

• Users may not know the answers to configuration questions, and are now blocked until they can find answers.

• Configuration during installation is nearly always significantly different from configuring (or 're-configuring') the product after installation. Again, this is confusing to the user.

• Migrating a working configuration to another system is harder when you have to configure during installation. Configuration should be easily portable between installations.

• It increases friction for end users who are trying to automate the installation of software for a large number of systems.

  Really, don't be that guy.

Software publishers need to respect the system on which their software is being installed. You don't own that system, the end user does. Here are some common scenarios that can be disrespectful:

• Launching directly from the installer. Installation should not be considered a good opportunity to launch your application. Similar to configuration issues, this is frustrating to end users who are looking to automate the installation, and can introduce confusion for users who may not have expected that.

• Automatically starting software at system start. The proliferation of software that insists on starting up with the OS automatically is getting out of control. Software that wishes to launch at start-up should get explicit opt-in consent from the user (after the user has launched the application at least once), not require the user to hunt down the option from a sea of configuration settings to disable it. Oh, and not providing a method to trivially disable auto-start is very bad.

• Checking for software updates. There are two acceptable methods for automatically checking for software updates:

  • Preferred: checking from within the application itself (i.e. at startup) and elegantly handling update and restart.

  • Acceptable: Launching an update checker via a scheduled task, checking, and then exiting.

  • Wrong: Auto-starting a background or tray application to constantly check for updates.

    Personal opinion: This last one is particularly frustrating. Since Windows doesn't currently have a built-in 3rd party update service (like Windows Update) that will periodically check for updates, download, and install them, many companies have resorted to running bloated, wasteful apps in the background, waiting for updates. This is terribly disrespectful to the end user's system, and offers absolutely nothing of value to the user that a scheduled task wouldn't accomplish with less effort.

Finally, regardless of underlying technology, there should be a common set of commands, tools, and processes that allow users to install any software in the way that they would like. Currently, we see that individual installation technologies are all headed in different directions, which makes automating the installation of some pieces of software a nightmare. We as a community need to have the ability to bring all of these pieces of software together without having to manually script each individual combination.

Garrett Serack (@fearthecowboy)

So why are we implementing PackageManagement? In the Linux world, people are familiar with package managers such as Apt-Get, YUM, RPM, etc, for different Linux distros.  In the Windows world, however, there are quite a few installer technologies, each having their own way to install software, such as MSI, MSU, APPX, and the list goes on and on. This creates a challenge for ITPros and DevOps and a need for a tool to automate the software deployment experience.  PackageManagement is aimed at solving this problem.  Let’s first have a glance at the architecture.

Architecture

PackageManagement is essentially a Package Management Aggregator.  It creates a unified and consistent PowerShell interface for users and provides a plug-in model at the back end that different installer technologies or package managers can plug-in as providers, using PackageManagement APIs.  Each provider further manages one or multiple package sources (repositories) where software packages are stored.

Regardless of the installation technology underneath, users can use these common cmdlets to install/uninstall packages, add/remove/query package repositories, which we call Package Sources, and query a system for the software installed.

 What’s in the box?

In the box, we will have

• PackageManagement Core component,

• a PowerShell module to provide cmdlets, and

• a key set of providers. 

That’s it, all other providers can be installed on the fly.  This allows for a small footprint while not losing agility to dynamically bootstrap package providers and install packages from those providers.

The key set of providers coming in the box are:

• a Bootstrap provider (the provider that knows where to get more providers from)

• an MSI provider for handling MSI files

• an MSU provider for handling Microsoft update files
• an Programs provider (Add/Remove programs) for providing inventory data of anything that registered itself with Add/Remove programs

• PowerShellGet -- for accessing PowerShell modules.

Quick Start

Let’s explore what PackageManagement can offer you. A handy Get-Command is a good start.

You can see that we provide three levels of management, i.e. provider, package source, and package. The cmdlets are pretty much self-explained. We are particularly interested at the Package level operations, so let’s explore further on the SDII operations.

Discover Packages

This will look at all package sources for the provider PSModule and return all the versions matching the package name.

Install Packages

Once you find the package, you can simply specify the version without specifying a package source and PackageManagement will install that version of package from the correct package source.

Inventory

You can specify the –provider parameter at Cmdlet get-package to check what’s installed in the local machine. There is a special provider Programs included. With –IncludeWindowsInstaller option, it returns a superset of packages comparing to the Add-and-Remove Program, which only lists those ‘volunteering’ registered MSI packages.

Where to get it for down-level platforms

Besides Win10, PackageManagement is available for down level platforms in a few ways:

• It is included in the Windows Management Frameworks 5.0 (WMF 5.0) Preview that supports back to Windows 7 and Windows Server 2008 R2. WMF 5.0 also contains PowerShell 5.0, DSC, and other components. 

• For users who only want PackageManagement, we will soon release a stable version of just PackageManagement and PowerShellGet provider as a MSI package, and plan to refresh it frequently.

PackageManagement is also an open source project at https://github.com/OneGet. You can check out the latest news and code from there.