Howdy y'all,

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)

(this is a repost of a page I wrote a couple years back at the dawn of the OneGet project)

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)

I'd like to have a moment of silence.

Yesterday afternoon, at 2:33PM my beloved work disk passed away. He is survived by his younger brother, the SSD boot disk, who, like our whole family of components is experiencing shock and grief in the passing of our deeply loved friend.

Moments after committing my last set of changes to source control, my work disk experienced some sort of catastrophic failure. While his passing was indeed quick, it would appear that from the god-awful sound that the disk makes when attempting to spin up, the last moments of his life would have been extreme agony.

At this time, technicians do not suspect foul play, merely an unforeseen and unknown defect laying in wait in his heart was a ticking time bomb, awaiting an opportunity to strike.

While the vast majority of data on the disk is backed up on other volumes, there are no doubt some ancient memories that have been lost forever.

I treasure the moments I had with this disk, and I will always remember him fondly. We've shared so much with each other, from vast ambitious projects, to stashing data that I surely meant to come back to one day.

Even in this hour of grief, our family looks to the future, and in doing so, would like to remind others, that all life is indeed precious and finite, and for the love of all information and knowledge everywhere:

BACK YOUR DATA UP. BACK IT UP NOW.

EVERY SINGLE DISK YOU HAVE WILL ABSOLUTELY DIE ONE DAY. 

With all the writing about OneGet that everyone's been doing lately, I thought it might be a good time to explain exactly what OneGet and Chocolatey's relationship is.

When we built the OneGet prototype that first shipped with the WMF 5.0 preview last April, the only provider that was even around was the hastily-written prototype Chocolatey provider that I built. Re-using the existing Chocolatey implementation at the time wasn't really feasible, as it would have meant shelling out to an external process, parsing the results and pulling them back in and then adapting that output to the format that the OneGet provider API was expecting.

At the time of that release, I knew Rob was planning on a new version of Chocolatey that would be build from-scratch implementation that cleans up a lot of the issues with the original as well as making it consumable as a library (chocolatey.core). 

Which is kinda why, over the last several months, I've delayed doing anything significant with my prototype implementation, or fixing many bugs with it.

Now, that new foundation for Chocolatey is becoming available.

This means that I can finally drop my prototype implementation into the bit-bucket and we can build a new provider based on the same code as the official Chocolatey client is using.  This will very shortly become 'THE' Official Chocolatey provider for OneGet; we're not going to fragment the ecosystem by continuing with a separate implementation.

Just to make that clear: We're not re-implementing Chocolatey. We're not forking Chocolatey. We're not taking control of Chocolatey. We're helping connect the official Chocolatey implementation into OneGet.

The new Chocolatey Provider project has been already created on github, the ever-so-illustrious PowerShell MVP @Jaykul is leading the development of the new provider. I'll be helping out with that, making contributions when I can too.

I'm hoping that we can get that up and running within a few weeks, and replace the existing provider fairly quickly. This will ensure that all future Chocolatey behavior in OneGet is heavily tied to the official Chocolatey, and we should see incompatibilities dry up completely.

If you'd like to contribute, head on over to the Chocolatey Provider Project on Github.

With a useful build of OneGet making an appearance in the Windows 10 Technical Preview (build 9926+) I thought it was a good time to stop and catch y'all up on what the heck is goin' on.

Before we get into all this, I would like to remind y'all that  OneGet is a work-in-progress -- you're going to find some rough edges, some things that don't quite work right, and maybe even some stuff that really needs changin'. That being said, I reckon that it's also in a pretty good state, and it's getting better every day. The upside about publishing bits like this is that you get to see the stuff as it's being made (and if you want to really feel that wild west experience, you can head over to the Github project and grab a really cutting edge build.)

For those tuning in for the first time, let me shine some light on exactly what we're buildin'.

OneGet is a Package Management Aggregator -- it's basically a core module that anyone can write a plugin (what we call Providers) and creates a consistent interface for software discovery, installation and inventory. On the one side of this core module, is a set of PowerShell Cmdlets that let the user work with all these different package management systems, and on the other is the interface for writin' package providers.

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

We've started a list of all the package providers that we'd like to see built. Some will be built by Microsoft, some by third parties. Over time I'd expect that there's gonna be quite a number.

What's in the box?

In-the-box, we're going to restrict how many of these providers that we ship-- and make it real easy to install new package providers on-the-fly. Think of it like this -- all we really need to have is the basic set that allows us to discover and install more providers for more types of software. Keeping the core unencumbered means that we can dynamically install and update the package providers with greater ease and agility.

At this point, we're likely going to keep the core set to :

• 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 ARP provider (Add/Remove programs) for providing inventory data of anything that registered itself with Add/Remove programs
• PowerShellGet -- for accessing PowerShell modules.

 

So, grab yourself a heapin' helpin' of OneGet and lets get started.

 

On a fresh install of OneGet, when you use the get-packageprovider cmdlet you will get a list of the currently installed package providers, which right now, doesn't look like much.

However, you can ask the hidden Bootstrap provider what providers it knows about: 

And, you can have it automatically prompt to install one by asking for it by name:

You could also have it just install it on-the-fly if you use it in a command:

ProTip: If you don't want it to bug you with the prompt, you can include the -ForceBootstrap switch on the command line.

 

Dip your fingers in some Chocolatey

Chocolatey is a community-run package management system that is tailored towards simplifying the installation of mostly developer/devops/itpro software. OneGet has a rudimentary Chocolatey-compatible package provider written for it. 

Once you've bootstrapped it, you can find some packages to install using the find-package cmdlet:

and installation is a snap:

 

IMPORTANT NOTE:

The current implementation of the chocolatey provider requires you to set the execution policy to unrestricted:

Don't use this if you're not comfortable with changing the PowerShell execution policy and what that means.

This will be fixed soon.

Movin' along...

I know that this has been the briefest of posts on OneGet, but I figured it was better to start the ball rollin', spill some beans and y'all can keep watchin' as I post more updates.

If you want to follow close along as this is being developed, follow me on Twitter: @FearTheCowboy