Windows 10 Gets a Package Manager For the Command Line

aojensen writes: ExtremeTech reports that the most recent build of Windows 10 Technical Preview shows that Windows is finally getting a package manager. The package manager is built for the PowerShell command line based on OneGet. OneGet is a command line utility for PowerShell very similar to classic Linux utilities such as apt-get and yum, which enable administrators and power users comfortable with the command line to install software packages without the need for a graphical installer. ExtremeTech emphasizes that "you can open up PowerShell and use OneGet to install thousands of applications with commands such as Find-Package VLC and Install-Package Firefox." It's a missing feature Linux advocates have long used to argue against Windows in terms of automation and scale. The package manage is open to any software repository and is based on the Chocolatey format for defining package repositories."

Comments

Respect

[nine-times]

I really respect this move from Microsoft. It's something they should have done a while ago, but better late than never. It has the potential to make administration much easier. They should also maintain their own repo of patches as an optional replacement for Windows Update.

Re:Respect

[His name cannot be s]

[FYI -- I'm @FearTheCowboy everywhere else, my /. id is so old that my name got trimmed from "His Name Cannot Be Spoken" 15ish years ago when they did a database adjustment... ]

I have had thoughts on how to do this; I suspect that while we may not set up a repo to do that, I may hack out the instructions on how that could be done easily if one wanted to maintain their own.

It really boils down to how much time I can throw at that.

Of course, we also want it to plug into WU and WSUS, but that'll be a bit more down the road.

Re:We can do that thing you like

[His name cannot be s]

Actually, to be perfectly clear, OneGet isn't really a package manager.

It's a package-manager-manager -- It's a unified way of installing packages of software regardless of the how-it's-implemented-on-the-back-end.

The first real package provider plugin is a Chocolatey one. Why re-invent the wheel when the wheel already works?

The purpose here is to leverage all these different sources of software using a common set of commands and APIs.

Anything that can be represented as a 'source' of software can be plugged in on the back end. I'm aiming for plugins for NPM, Ruby Gems, Python, on top of the expected MSI, Chocolatey, NuGet, etc...

Plugins can be written by anyone, and I'm going to great lengths to make it as simple as possible -- it's about ~15 or so functions to implement and we can plug in virtually any package format or service into OneGet.

Re:We can do that thing you like

[Anonymous Coward]

What this article forgot to mention is that this project actully IS Open Source, under tha Apache v1.2 licence and hosted on GitHub.
https://github.com/OneGet/oneget

Re:We can do that thing you like

[benjymouse]

https://en.wikipedia.org/wiki/...

Rather than leaving the dependency resolving responsibility to package maintainers, the Windows OS contains a brokering mechanism that will load the correct version of an assembly - even if multiple versions of the same assembly exists in the global assembly.

Linux package managers have dual responsibilities: Provide available software (with update mechanism) and ensure dependency hell does not rear its ugly head. Linux dependency hell is very real, once you step outside the repositories.

Windows has binary compatibility with software that was developed for Windows 95 / Windows NT 3.1 (where Win32 debuted). The dependency problem (called DLL hell in Windows) was solved with the SxS and the broader use of the Windows Installer package manager, which integrated with SxS.

Re:We can do that thing you like

[benjymouse]

The installer should put abc.dll in the same directory as the .exe file instead of a shared location.

No!

If the DLL is indeed candidate for being shared (e.g. part of a shared product) it should put the assembly/DLL in the Global Assembly Cache (GAC). This is a side-by-side store where the same assembly/DLL can exist in multiple versions.

If security vulnerabilities are found and a patch is released, only the version in the GAC needs to be updated, often by registering a new version with a manifest/redirection that will ensure that anyone requesting the old (vulnerable) version will be treated to the new (fixed) version.

Windows Installer does this. And supports patching.

Re:We can do that thing you like

[VGPowerlord]

DLL hell was *very* real in the Windows 9x days. Side-by-side assemblies was introduced with Windows 98SE (IIRC) - but really only became de rigueur with Windows XP. During the 9x days, software developers took advantage of the fact that nothing prevented them from writing files to the system directories. When they encountered a problem where they needed a DLL - they simply installed it in the system directory - often overwriting whatever was there before. Obviously this caused all sorts of problems where only the latest installed product had a robust state.

To add to this, Microsoft shipped a faulty copy of mfc42.dll with Visual C++ 6. It removed a bunch of functions.

Now, keep in mind that mfc42.dll was used by any MFC applications compiled by Visual C++ 4.2-6.x... including Netscape, Microsoft Publisher, and a number of other programs.

Oh, did I mention that MFC was the recommended way of writing Windows programs back then?

Incidentally, Microsoft started including the VC++ version number in its DLL names again after this thanks to that screwup... which they had done before (vc++ 4.1 had mfc41.dll, etc...)