10 things about OneGet that are completely different than you think.


 

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 3rd 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 3rd 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)


Comments (6)

  1. Peter says:

    So… let me get this straight. In point #1 you're saying it's not a package manager and in point #10 you're saying it's going to be renamed to package management?!

    Honestly, after reading this article I'm left with "so, what's the point of this thing?" It seems like the lowest common denominator between various installers (can't really call any of them a package manager). If I want to install Node and Python modules, then why wouldn't I use their respective package managers and get all their features rather than a subset?

  2. @Peter,

    Yes, it's named "PackageManagement" a subtle difference from "PackageManager" to be sure, but a difference none-the-less.

    And yes, if you're happy using the existing package management commands, by all means, continue to use them, and completely ignore this.

    However, there are users that aren't aware of how to use them (or in some ways, even get one of them onto their system). And, as we get more and more providers involved, it offers some consistency for users to use the same commands, regardless of where or how their software is installed.  At some point in the future, it'll be nice to be able to say "update-package *" and have it do that for all the software you have installed, regardless how it got there.

    And that being said, there are a number of providers being implemented that don't currently have a standalone version, and their first incarnation is as a OneGet provider.

  3. eosfor says:

    Msi PowerShell module has an option to uninstall software. Do you really need to implement Program provider?

  4. @eosfor,

    In the ARP table, there are more than just MSI installations, so, yes absolutely, we need the Programs provider, it's there to provide inventory of all the items in Add/Remove programs.

    Now, slightly more pointed question would be, given that there is an out-of-box 3rd party MSI PowerShell module, why do we need a MSI provider for OneGet?

    Well, a couple of reasons; first, the MSI PowerShell module isn't included in Windows. Second, for all of it's power, it's doesn't work as the plugin to OneGet itself, which means that the common commands wouldn't be there for MSI files.  

    Really tho', both the MSI powershell module and the OneGet MSI provider use the same underlying DTF libraries to implement their functionality, with the MSI PowerShell module having a much richer interface.

  5. Rory McCune says:

    Interesting and good clarification on what you're doing with OneGet/PackageManagement.  A challenge I can see with your approach is that people might think that an "MS Approved" solution addresses the big issue of "can I trust software downloaded via this mechanism".

    Now from what you've said here I guess the answer is that you're delegating that to the repository providers and letting users make their own decisions on trusting those providers.

    That's kind of a shame (to me) as there was an opportunity here for MS to create a system that allowed for "apt-get" style installation of packages with a known provenance.  Instead we're left making decisions about community supported repositories who, unfortunately, don't have the kind of resources necessary to thoroughly vet software in the repository.

    To use Chocolatey as an example, I recently used it to install windirstat, and noticed that it's just downloading the file over an unencrypted HTTP connection from sourceforge. No package signing, no HTTPS connection….

  6. @Rory,

    As we proceed, that's exactly the kind of thing that we'd like to implement. At the very least, we're going to work with the community to set standards for how a provider should behave, and then we (as a community) can review and decide what providers are validated.

    Further to that, we'd actually like to make the whole notion of trust "pluggable". Some companies may require that software in their own enterprise be on an approved list, or signed by some key, or some other criteria. Rather than forcing a one-solution-for-everyone approach, the providers can be hooked into this notion of trust verification, and we can offer far greater flexibility than that.

    I'm actually looking to squeeze in smartscreen filtering as soon as I can to provide at least an initial vet of the files coming into the system.

Skip to main content