What is Reddit's opinion of
OneGet?
From 3.5 billion Reddit comments
42 reviews of this app found across Reddit:
Windows 10 will have a command line package manager. Here is the source code.
IIRC it won't have the best feature of the linux package managers though, dependency management (afaik the devs want to introduce that in a later version of Windows).
Misleading heading.
It's not a manager of package managers,
but more like a "universal" package manager that supports multiple types of packages, including Chocolatey.
Nice post!
ctrl+f oneget - No results.
Have you heard of OneGet? You mentioned framework multiple times but don't seem to mention the actual framework Microsoft is pushing with Windows Management Framework 5 (and which may be down-level compatible), that includes Chocolatey as one potential repository (untrusted, by default).
Here's an old response that might have a few links in it, although there have been changes to both OneGet and WMF 5 since then.
Cheers!
Chocolatey is pretty much officially endorsed by Microsoft.
People will call NuGet or PackageManagement "package managers", but they're not in a Windows context. NuGet packages are only meant for blobs, there's no installer logic like AppX or MSIX Packages. PackageManagement (formerly OneGet) is a package manager Manager (it manages other package managers). It has the concept of providers, where NuGet is one provider. It's up to others who actually provide packages to write a PackageManagement provider.
The reason I said Chocolatey is "pretty much" officially endorsed, is that they planned for a massive colab between the Chocolatey community and the first beta testers of Windows 10. Microsoft released a beta version of a Chocolatey provider for their new PackageManagement module (called Chocolatey), but apart from making rounds in niche communities, nobody cared. You still had to do some setup with installing the Chocolatey provider and setting it as trusted.
Microsoft abandoned the module a few months after the first Windows 10 release in 2015 and Chocolatey quickly broke support for it after some changes in 2015-2016. You could already install the nuget.exe tool at that point, which was also much more feature complete. Chocolatey would themselves release a new, more feature complete provider for PackageManagement (called ChocolateyGet), but to absolutely no fanfare. It even uses choco.exe under the hood! It supposedly still works, but why the fuck would you do it today. It's a bygone dream that never came to be.
Why use Chocolatey directly, when you can use the built-in PackageManagement (nee OneGet) package manager manager? It supports Chocolatey as a package provider, as well as others (nuget servers, local MSIs and MSUs, and many more).
It's confusing, but I'll sum it up as good as I can:
OneGet is an open-source project which is a package repository manager. That means that if you have a third-party repository (PowerShellGallery, Chocolatey) or any other OneGet-compatible repository, you can plug it into OneGet and manage all of your repositories from one manager.
Microsoft partnered with the pm of OneGet to include it in Windows, but for inexplicable reasons had to rename it to PackageManagement to ship it in Windows. It is included as a PowerShell module. Repositories in this PackageManagement-world are called "PackageProviders".
Microsoft were stupid and internally made a Chocolatey PackageProvider (called "Chocolatey") for the Windows 10 Technical Preview (before Windows 10 was shipped in 2015), a prototype they never touched again. It is now incompatible with Chocolatey. Chocolatey had to make their own PackageProvider (called "ChocolateyGet"), which is essentially just a PowerShell wrapper for their choco.exe.
So, to install the new ChocolateyGet provider, you have to run following PowerShell command (add -Verbose if you want info for troubleshooting):
Install-PackageProvider chocolateyget
You'll can download the experimental build of OneGet from http://oneget.org/oneget.zip -- It should run on WMF 3.0 (PowerShell 3.0)
You should be able to run the experimental build on Win7+
If not, file me a bug at https://github.com/oneget/oneget/issues
So a brief bit of googling turned this up. It seems that, on some level, RequiredModules should be used for all internal and external modules that your module depends on. ExternalModuleDepencies apparently identifies which modules you're not including in the package itself and must also be obtained somehow/somewhere. So you'd list internal dependencies once in RequiredModules and external dependencies twice (once with name and version in RequiredModules and once by name only in ExternalModuleDependencies).
The UWP install model is based on package management that is actually open (OneGet) and really is just a PowerShell command to install the package.
One could just write a normal UI installer on top of that and make sideloading really easy for the end user - even easier than the usual MSI.
Yes, it breaks the laws of software installation, but you have to be smarter than the installer. This issue comes up every time Java is mentioned, and the solution is always mentioned, so I'm not at all sympathetic at this point if people haven't made the change.
>1. OneGet is not a package 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.
>2. OneGet is not another implementation of Chocolatey [...] 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.
That's the big one for me. Reading up on OneGet just a few days ago I was really confused to what it was actually supposed to be. This seems to make a lot of sense to me too. A package manager like we're used to from unix would be nice, but that would only work if the repositories are as plentiful as they are on unix too. This looks like a good compromise to me, as it can just incorporate traditional installers. All it needs is a source to download the from.
I'm really interested to see where this goes. With all the installing (and de-installing) of software we do, I would like to see something like this make my life just a little bit easier. If I could install most of my software with a line of code instead of having to download/install/delete a couple of installers manually, I'd already be happy. After all, I'm basically already doing that with my games.
Sure there's stuff like ninite, but I'm always happy to see more solutions that are available from the get-go on a freshly installed system. 3rd party tools should always be the last resort imho.
Well, at a minimum, RuckZuck's provider looks like it's ready. https://github.com/OneGet/oneget/issues/77#issuecomment-93041661
There are definitely a few other competitors to Chocolatey (Zero Install) that are working on providers, and there's a provider in the works (but not finished) that uses the new choco/chocolatey.lib https://github.com/Jaykul/ChocolateyProvider
RuckZuck looks pretty interesting (I haven't had a chance to try it), they claim they can successfully discover pre-installed software and provide updates for it, plus they have the OneGet provider, and they also have RZ4ConfigMgr which lets you import software from the RuckZuck repository into SCCM 2012 R2, and creates the Application, DeploymentType(s), etc., for you.
Good reason, and I'm happy to help. But it was funny. To me. :)
Seriously, it's the best way and totally obsoletes batch. There are built-in aliases for ls,cp,rm,cat, etc. Can do regex natively (they didn't make an alias for select-string, though). Object-oriented. Syntax is like Perl and Python. Has an SSH equivalent. Been around 8 years. Last but not least, RPM workalike is coming with OneGet, and CPAN analog as well with PowerShellGet.
Not by default.
I have heard that a new "one-get" feature for powershell will support chocolatey packages.
Github Page
https://github.com/OneGet/oneget
That means you could just use the one-get command to install cygwin for ssh support.
Also you could just install putty probably.
I wholeheartedly agree of making sure that your choice and preferences are the most important factor. Don't want updates? Don't take em. Don't want bundled crap? Don't take em. Law #1 is "User Control and Consent" (https://github.com/OneGet/oneget/wiki/8-Laws-of-Software-Installation )
Really tho' if you're not interested, then no worries. You never even need to worry about OneGet. It's not there to force changes upon you. It doesn't mandate any package format.
> When it's integrated with Composer, and extensions are managed for me, based on my project dependencies, then you've got my attention.
I do believe that's the end goal. The pickle RFC mentions Composer compatibility, and the corresponding tracking issue in Composer is #2898.
Also, on a somewhat unrelated note, I believe Pierre may hope to integrate with OneGet for the Windows side of things. That may be outside of the RFC's scope, but I recall Nils mentioning it a couple of months ago in a conversation about this project and Composer.
On the other hand, looking through the source code, the "programs" provider might be querying the same popular key.
Line 132, the GetInstalledPackages method. Testing should be done, but it's querying the "HKLM\Software\Microsoft\Windows\Uninstall" key, so it should return all you need, except if it's filtering something off. I'm not good enough at C# to figure it out.
4.19. They're sticking to long-support releases according to this.
WSL gives you a choice of Ubuntu, Debian Fedora, or openSUSE, and you can also buy Pengwin, a distro designed to work better with WSL, so their respective package managers. Pengwin uses apt. You could also install your own, just like you can with a native Linux.
Unrelated, but Microsoft made a package manager for Windows called OneGet.
Are there any potential network related roadblocks? SSL hardening initiatives, internet access blocking, port blocking, etc?
EDIT: Also, this post: https://github.com/OneGet/oneget/issues/183 talks about TLS versions perhaps behind the issue. The poster was seeing Event ID 36871 in their system logs.
EDIT 2: This guy installed Chocolatey to fix it: https://stackoverflow.com/questions/37474742/unable-to-find-module-providers
You misspelled OneGet/PackageManagement. It's not a Package Manager. It's a Package Manager Manager, and can use Chocolatey as one of its package providers.
OneGet is a Windows package manager, renamed as PackageManagement. It is a unified interface to package management systems and aims to make Software Discovery, Installation and Inventory (SDII) work via a common set of cmdlets (and eventually a set of APIs). 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. With OneGet, you can Manage a list of software repositories in which packages can be searched, acquired, and installed Search and filter your repositories to find the packages you need Seamlessly install and uninstall packages from one or more repositories with a single PowerShell command
Source: https://github.com/OneGet/oneget
Despite they calling themselves a "package manager", it is really a "package manager manager". Or a "unified interface" for package managers.
Not a dumb question at all! It's covered in the OneGet Q&A on their Github page.
Essentially they're taking the idea and adding better support for this scenario that Chocolatey basically kind of fudges at times.
Exposure via API allows for more advanced scenarios as well, which can be useful for devops (at least that's what I'm planning on using it for).
Actually they're documenting the package management on github.
https://github.com/OneGet/oneget/tree/master
One of the package repositories is going to be chocolatey, which works really good given it's maintained by volunteers.
Oneget/Windows 10 Package management isn't so much a singular package manager but a framework for package managers built in other languages like C# and VB. Basically it gives you a way to add package managers like chocolatey to windows through powershell.
One of the things that we're looking at is how to let users decide how to trust a given package (or repository). Some things that can factor into that are: * does the package contain 'custom actions' during install (ie, actual code/scripts that run at installation) * what dependencies does the package have * does it have nested installations (ie, bringing along 'XYZ toolbar')
My philosophies behind the direction I want to take OneGet are covered in my "8 Laws of Software Installation" -- https://github.com/OneGet/oneget/wiki/8-Laws-of-Software-Installation
I don't yet have answers how we're going to solve everything (and, when we solve something, how we can expose that to the user) but if you're interested in help think things thru, feel free to start issues in the github issues tracker (https://github.com/OneGet/oneget/issues) or better, join the weekly discussion (http://oneget.org/weekly/meeting.html)
Yeah. OneGet. Packet manager for Windows.
It's not really part of Windows 10, it's part of the Windows Management Framework 5, but it's included in Windows 10 Preview. Unfortunately, there is not really any useful packages to install (it's missing the Chocolatey package source), so you need to upgrade to the newest version of OneGet from here: https://github.com/OneGet/oneget or just add the Chocolatey source yourself.
It looks like this is an ongoing issue:
https://github.com/OneGet/oneget/issues/400
Make sure you only have one version of PowerShell Core installed (i.e. you should only see the '7' directory under C:\Program Files\PowerShell. If you have a preview or version 6 installed, then uninstall them. If that doesn't work, completely uninstall PowerShell Core and reinstall.
(Note: Don't touch anything related to Windows PowerShell, just PowerShell Core - i.e. stuff under C:\Program Files\PowerShell)
PackageManagement, which is the built-in version of OneGet.
Things get a little meta when you use Powershell PackageManagement with Chocolatey core to install Powershell Core, which itself includes PackageManagement and Chocolatey ...
What benefit does this have over using the official built-in Powershell PackageManagement/OneGet? Other than OneGet is really a Package Manager Manager, anyway (it relies on other package management sources like Chocolatey and nuget to do actual package installation and removal; it instead manages those package managers in a unified interface).
It does have some 3rd party packaging support using "NuGets". There's a framework for it using Powershell on which an experimental package manager from Microsoft called OneGet (now just called PackageManagement) built on. There's a similar but 3rd party package manager called Chocolatey which I prefer and use for most of my applications installed on my dev machine.
As for privileges, it depends on commands run as admin, there's also a GUI but I would think it also needs to be started with Admin privileges on startup. Advantage though is that you only need to give the privileges once when updating all programs.
I already did that, thinking I wasn't going to get useful responses here and it seemed best. I'm happy with it so far.
I first searched for info on OneGet, which is built into Windows 10, but surprisingly it can't upgrade packages!
Dá para instalar vários repos (incluindo o chocolatey que é capaz de já vir instalado). Pesquisa por PackageManager que é o nome do módulo. Ou o nome antigo, OneGet.
É baseado no NuGet, que eles já usavam há algum tempo.
> look into chocolatey, it's like apt-get for windows, and has a git package, and an option to put it on your execution path for you
I'd also keep an eye on OneGet. It's a package manager manager, and includes Chocolatey as one of its default package manager sources.
hey man, i read the about oneget and had a quick look at the gallery of powershell packages, but honestly it all just flew over my head :-/
i really don't know what it is, i don't understand, but it sounds cool and all. i'm not sure if this screenshot is representative or not?
if it is, would be nice if there could be a more average-user friendly interface :p
i had a look at a few more gallery modules, and the very brief descriptions and complicated title name, makes it very hard for me to understand what each thing does!
Why not use OneGet? It's a package manager manager, and it has a "PowerShellGet" repository that pulls from a common PowerShell Gallery. Most tweaks, registry or policy or otherwise, can be implemented as powershell scripts, loaded up on PowerShellGallery, and then retrieved with OneGet.
Or you could build your own repository for OneGet to pull from.
It's being shipped with Windows 10 next Wednesday, and the April preview release is very functional. First thing you need to understand is that PackageManagement is not a package manager; rather, it's a package manager <em>manager</em>. It exposes an interface that will allow package manager developers to implement a PackageProvider, and then allow end users to install software using any installed PackageProvider using a single, simple, consistent PowerShell (and GUI in the future) interface. So, for example, support for Chocolatey is currently provided by the core NuGet PackageProvider (as a test case). Upstream Chocolatey is working on an independent, production-ready PackageProvider that, hopefully, will ship soon. PackageManagement also currently has providers for:
- PSGet (for PowerShell modules)
- MSI and MSU packages
- the Add/Remove Programs system (just removal for now)
with more coming in the future. Check out the link above.
That actually looks quite sexy... this together with oneget and being able to have virtual desktops are making Windows 10 very attractive to me. Specially considering many of these extensions shipped with Windows are open source.
Perhaps the remaining thing would be a proper location for binaries in the PATH. The PATH in windows is such a mess because each program installs its binaries somewhere else. I'm hoping oneget would start setting some standard place for shim executables.
I know for windows oneget they'll actually be adding support for chocolatey, which means it will be included by default. The problem is that it's still in development so using oneget may be kind of buggy at the moment.
Still for an open source effort headed by microsoft (which sounds nothing like the microsoft of 10 years ago) it sounds amazing.
https://github.com/OneGet/oneget
They've done some cool stuff with their powershell software.
edit: For those of you in the future, OneGet is added to Windows 10. I think they're officially calling it "PackageManagement" but don't quote me on that.
It is open source, here's the source code. From the looks of it, it has a plugin system to add support for new package protocols, which could be made to support adding repositories.
From what I'm seeing of windows 10, it's like if windows 7 had more touch stuff. There's the tablet apps, but they're universal now, you can literally click a button and those annoying full screen apps become resizeable normal apps.
In addition having the "metro" updating icons will prove useful if you want access to a calendar or the weather. I can just peak at the start menu for the current temperature, rather then download something like weather bug or search online.
Another cool thing I'm expecting with windows 10 is OneGet.
It's like the linux package management systems but based on powershell. It's also compatible with chocolatey.org, for normal apps.
Also OneGet is being worked on by microsoft, is opensource and apache licensed.
OneGet is the microsoft offshoot of chocolatey https://github.com/OneGet/oneget But is very much not for prodcudtion yet. Give it 1-2 years before if becomes a working part of windows. There have been many attempts at apt/yum implementations for windows but they have never got far, not much of a community to support them
The best long-term option would probably be to either create a new provider for OneGet, or to add functionality to the Chocolatey provider for building packages from source.
You won't have to for much longer. When WMF 5 is released, it will basically have the same thing built in, just renamed. It even accesses the chocolatey repository. This is an example of how to use it.