Is there a way to set ChocolateyGet's package source as trusted?

[CMCDragonkai]

Using Get-PackageSource doesn't show chocolateyget's source. Every time I install a package it asks about the fact that https://www.chocolatey.org is untrusted.

[jianyunt]

You are right. The register package source feature is not supported in the ChocolatetyGet.

[KZeronimo]

Thanks for the work on ChocolateyGet - its good to see the unification coming to windows package management

1. Are there plans for Register-PackageSource
2. Currently an Import-PackageProvider is needed either at the command line or via Profile.ps1 - it would be nice if the provider were delivered as a dll like nuget and installed at C:\Program Files\PackageManagement\ProviderAssemblies - my understanding is that it would then simply load into every PowerShell session

[KZeronimo]

Just did a little more digging and understand that ChocolateyGet may be a gap filler

I see you've posted a few times - are you contributing to the "official" Chocolatey-OneGet

[jianyunt]

@KZeronimo, if I remember correctly, you can directly use the provider without needing to explicitly import. for example

install-module ChocolateyGet
find-package -provider chocolateyget -name *firefox*

I remember I added this feature in PackageManagement (OneGet) for WIn10 anniversary, Windows Server 2016, WMF 5.1. Or you can simply refresh the PackageManagement version by install-module PackageManagement -force.

Looking at chocolatey-community/chocolatey-oneget#5, Rob seems to have time on to finish the Chocolatey-Oneget provider.

[Gregoorio]

Hi jianyunt
When will the Chocolatey provider be available for public?
Is it possible to register your own repository via powershell not choco?
I mean the register-packagesource ..... command with the Chocolatey provider (GET).

[jianyunt]

@Gregoorio, Rob is working on the official Chocolatey-OneGet provider.

For the ChocolateyGet, are saying you want to download packages from your local repo not from the https://www.chocolatey.org?

[Gregoorio]

jianyunt. Yes, I wrote to Rob about it.
Rob told me that the chocolatyPrototype is not supported.
I would like to register my own repository using native commands powershell (not choco) via Register-Packagesource using Chocolatety-Get (official supported) provider, but I see above that I can't use register-packagesource with provider Chocolatey-Get.

When will an official provider for powershell appear?

[jianyunt]

So far we have 2 providers:
chocolatyPrototype - only works with a few packages. not recommend to use.
ChocolatetyGet: For the time being, you may use this provider.

The official provider, Chocolatey-OneGet provider will be from Rob who is saying he is working on it.

If I add support to allow you register-packagesource in ChocolateyGet, that will resolve your problem?

[Gregoorio]

If it will be possible to register a local repository with chocolatey-get (which is supported, using commands register-packagesource...)I think it should be ok. I would rather use an official supported provider for powershell (not choco).

[Gregoorio]

@jianyunt,
I would like to know if you were able to add register-packagesource provider ChocolateyGet?

[jianyunt]

It will need time to implement add-packagesource and remove-packagesource in the ChocolateyGet code to support register-packagesource. I am tied up with other project right now. Thus my short answer is I won't have time to do so right now, but maybe later. Also I am open to take PR for anyone who can help on this.

[Gregoorio]

@jianyunt. I've contacted Microsoft about the release of an official chocolate provider. For the time being, Microsoft will not provide an official provider for Chocolatey. Is there a chance that this project will be implemented at all?

[jianyunt]

@ferventcoder, Rob, do you have the answer to the above question from @Gregoorio?

Long discussion here too: chocolatey-community/chocolatey-oneget#5

[ferventcoder]

@jianyunt howdy - I can give it a shot.

@Gregoorio I can understand your frustration waiting to see an official implementation. Microsoft did start one but only made a partially functional prototype (the current Chocolatey provider). The person we were originally going to work with left the team and wasn't able to continue working on this aspect. The other side of the coin is that we've been working in our open source channels at Chocolatey Software to find some community members that can assist us with this aspect. We prioritize nearly all of our work with our customers (likely Microsoft does similar here). Unfortunately OneGet/PackageManagement doesn't provide a means to upgrade (at least not a command like upgrade/update), nor do our current customers seek to add an additional layer into the mix - that means this doesn't fall into our prioritization schedule. If your organization feels this is extremely important, you have a few options:

• Preferred: Contribute code to move the provider forward and finish it - you and/or someone in the community (Preferred)
• Also preferred: Look to using choco directly until there is an official option and reevaluate at that time. Or use with this provider (ChocolateyGet).
• Wait for the prioritization schedule to open up so that the official provider could get implemented by the Chocolatey team.
• Your organization engages with Chocolatey Software and contributes to the costs of feature development to finish the provider on an accelerated schedule that would be more agreeable with your needs.

If you are interested in the latter, please have someone in your organization reach out to us through the https://chocolatey.org website contact page. HTH

[AlexisColes]

It would be great to see this feature, I am missing this too. I have been implementing my own desired state configuration resource to install chocolaty packages up till now in the hope that this would get sorted out.

PackageManagement and chocolaty seem like such a powerful combination I can not believe that you wouldn't priorities this, it seems like a match made in heaven.

Anyway, would love it if you could, maybe I will try to contribute when I am back from holiday.

But just having the ability to add a private package source to the chocolatyGet would be perfect, that provider seems to work very well, but I really need to be able to use some of our private chocolaty packages.

[stinos]

PackageManagement and chocolaty seem like such a powerful combination

This. In my opinion there isn't really one 'true' package management system yet, and MS did a good job of creating OneGet as a step towards it. With ChocolateyGet we are very close to just being able to fire up Powershell on a fresh installation and run over a script, wait, and some time later have a proper dev environment. Like on other OS. Fixing this issue would be one step closer. Then there's still proper Update-Package support, passing options to the installers (and/or choco.exe), and maybe some other things I'm missing (not sure how well Uninstall-Package does it's job?)

[AurimasNav]

Preferred: Contribute code to move the provider forward and finish it - you and/or someone in the community (Preferred)
Also preferred: Look to using choco directly until there is an official option and reevaluate at that time. Or use with this provider (ChocolateyGet).
Wait for the prioritization schedule to open up so that the official provider could get implemented by the Chocolatey team

Looking forward to it, since interacting with choco packages via PackageManagement seems so much more flexible.

[CMCDragonkai]

Is there an immediate answer to the original issue or marking chocolatey.org as a trusted source?

[jianyunt]

You can use -force to avoid prompt for packages. e.g,

install-package 7zip  -ProviderName ChocolateyGet  -verbose -force

[AurimasNav]

Is it currently possible to use private repositories with ChocolateyGet?

[jianyunt]

This provider follows the syntax/protocol of the chocolatey.org. If your private repo is cloned from the chocolatey.org, then you can simply change the line 11 to point to your own repo. Then it should work.

[ferventcoder]

@jianyunt ouch. I thought that if someone set the sources in choco to internal, this would simply use whatever the default sources are set to.

[jianyunt]

I missed implementation of a couple of methods Add-PackageSource and Remove-PackageSource in this provider to do so. As of 2017, I am tied up Azure cloudshell. I will finish up this one if I have time during my vacation.

[jianyunt]

Or I guess I can add something like additionalparameter to let users to pass in parameters to choco. There is another issue for proxy support. I think that can be done though additionalparameter.

[ferventcoder]

Would a plural AdditionalParameters be a better name?

[ferventcoder]

Or ChocoOptions

[ethanbergstrom]

Forked the project and added logic for PackageManagement sources proxying choco resources, borrowing heavily from @jianyunt's Microsoft MyAlbum sample provider.

Choco sources can be added, removed, inspected, and referenced during installation via Register-PackageSource and the PackageManagementSource DSC resource.

Main limitation I ran into is that choco search only returns package name and version, not source, so I had to feed PackageManagement a generic 'Chocolatey' source name that will return when querying for individual packages.

My goal with this is to use pure PackageManagement DSC resources for setting and using internal repos so I can easily switch to using the official Chocolatey PackageManagement provider when/if it becomes available.

[jianyunt]

@ethanbergstrom are you considering to submit a PR to merge your work here?

• In the MyAlbum sample, i chose to save the user package sources to an xml file, similar to nuget package source, nuget.comfig. But you can choose other file format such as Json if you want.

• In the current implementation of ChocolateyGet, i hardcoded $script:PackageSource = "https://www.chocolatey.org". However there is an AdditionalArguments parameter, people can pass the generic choco commands parameters through it. If you do not want to deal with any config files and implement add-packagesource, remove-packagesource ... you can remove the hard-coded packagesource and replace it with the one from AdditionalArguments at runtime if -source specified in find-package, install-package... This is another way I thought earlier to allow to pass in different package source.

• Or Possibly add Source in the Get-DynamicOptions to allow user type -source?

• If you go for supporting Register-PackageSource, then the existing scenario (e.g., people do not run register-packagesource) should be continued supported. No breaking changes. You may consider https://www.chocolatey.org as default packagesource in that case?

[ethanbergstrom]

@jianyunt I'm interacting with chocolatey directly for source information. If you add a source through choco.exe, it will show up in Get-PackageSource, and likewise a source added through Register-PackageSource will show up under choco source.

It does continue to use the choco source chocolatey as the default if no source is specified into Find-/Install-Package, so it should be passive for existing users.

I'll go ahead and open a PR if you'd like to review further.

[jianyunt]

Thanks @ethanbergstrom. I will review your PR.

[ethanbergstrom]

FYI, I updated the PR with a few other things I've found in usage, namely being able to pass args/params to packages and their dependencies while not breaking Find-Package / choco search when called by DSC, and speeding up installs that have embedded installers (progress output from choco when downloading large packages was slowing it down tremendously).

[sgryphon]

Bump. Any update on when this PR might get merged & rolled out?

[ethanbergstrom]

Been using my fork for the last couple months in prod against our private package repos. At some point I'd like to look at reorganizing it into separate files, but overall I'm pretty happy with how it runs. See #15

[jianyunt]

Sorry I have been tied up with my other projects. @ethanbergstrom and @sgryphon, my understanding is we are ready for merging the PR #10? If so, I will merge it and update the module in the PowerShellGallery.com.

[ethanbergstrom]

I think it's ready.

[ethanbergstrom]

I've closed PR #10 in favor of PR #15 which contains several new features and a complete refactor of the code to remove duplicate logic and improve readability.

[ethanbergstrom]

With the current pull request still open, I've published a new module called Chocolatier on PSGallery that's essentially refactored ChocolateyGet with the multi-source logic, DSC compatibility, and a few others odds and ends for those who need those additional features without having to manually download and package my fork from GitHub, though my preference would be to merge these changes into the original project.