Chocolatey - the package manager for Windows
Home Page: https://chocolatey.org
License: Other
See https://github.com/chocolatey/choco for further development
Apache 2.0 - see docs/legal (just LEGAL in the zip folder)
##Please see the wiki
See docs/legal/CREDITS (just LEGAL/Credits in the zip folder)
This allows items to better take a dependency on a certain version of Chocolatey. Ensure that $chocolateyInstall\lib\chocolatey\chocolatey.nupkg exists and it is a valid nupkg file.
When attempting to push a package, always convert the package file path to the full path in case it was either a relative path or no file path at all (just the file name).
Some folks want a global confirmation setting so that chocolatey can work like the prior version did without confirmation. They understand the security implications of this setting, so allow them to change it.
allowGlobalConfirmation
Relates to #54.
Alternate runners ~= alternate sources
etc
This involves really designing the process and I have ideas in head for this one so restricting this to core team only.
Implement a custom PowerShell host. This allows for the following:
By default use the internal PowerShell host. Allow using the system
host either by shutting off the feature or by using a switch
--use-system-powershell.
When running PowerShell operations, use a built-in PowerShell host by
default, allowing fallback to the older method of running Posh
by calling an external process. By building against the oldest version
of System.Management.Automation that aligns with the oldest Windows
Operating Systems supported, we can guarantee this will work on every
version of Windows where Chocolatey is supported.
In case we do run into issues, attempt to resolve the PowerShell
assemblies starting from the newest version and falling down to the
older versions until one is resolved or no version is resolved. There
is a known assembly that will go through this process every time -
System.Management.Automation.resources, en-US. To see those assemblies
go through, one must ask for both debug and verbose output.
This reverts the changes for GH-249 in 9936876 and the changes
from GH-349 in 344268b so that both paths (system powershell
and choco's built-in PowerShell) run with similar output and because by
default in d523e7b (GH-445) choco no longer fails on the
presence of stderr output.
This resolves chocolatey-archive/chocolatey/issues/472
Relates to chocolatey-archive/chocolatey#661
This looks due in part to the folder not package information folder not being created.
C:\codelocal\chocolatey2\code_drop\nuget [master +0 ~1 -0]> choco pin add -n ruby -version 1.9.3.54500 -d
Chocolatey v0.9.9.0
Chocolatey is running on Windows v 6.1.7601.65536
Command line: "C:\ProgramData\Chocolatey\choco.exe" pin add -n ruby -version 1.9.3.54500 -d
Received arguments: pin add -n ruby -version 1.9.3.54500 -d
Configuration: CommandName='pin'|ContainsLegacyPackageInstalls='True'|CommandExecutionTimeoutSeconds='2700'|Sources='C:\ProgramData\Chocolatey\lib'|Debug='True'|Verbose='False'|Force='False'|Noop='False'|HelpRequested='False'|RegularOuptut='True'|PromptForConfirmation='False'|AcceptLicense='False'|AllowUnofficialBuild='False'|Input='add'|Version='1.9.3.54500'|AllVersions='True'|SkipPackageInstallProvider='False'|Prerelease='True'|ForceX86='False'|OverrideArguments='False'|NotSilent='False'|IgnoreDependencies='False'|AllowMultipleVersions='False'|ForceDependencies='False'|Information.PlatformType='Windows'|Information.PlatformVersion='6.1.7601.65536'|Information.ChocolateyVersion='0.9.9.0'|Information.ChocolateyProductVersion='0.9.9-27319d4e'|Information.FullName='choco, Version=0.9.9.0, Culture=neutral, PublicKeyToken=79d02ea9cad655eb'|Information.Is64Bit='True'|Information.IsInteractive='True'|Features.AutoUninstaller='False'|Features.CheckSumFiles='True'|ListCommand.LocalOnly='True'|ListCommand.IncludeRegistryPrograms='False'|NewCommand.AutomaticPackage='False'|SourceCommand.Command='unknown'|FeatureCommand.Command='unknown'|PushCommand.TimeoutInSeconds='0'|PinCommand.Name='ruby'|PinCommand.Command='add'|
_ Chocolatey:ChocolateyPinCommand - Normal Run Mode _
Chocolatey had an error occur:
System.ApplicationException: Unable to find package named 'ruby' (version '1.9.3.54500') to pin. Please check to ensure it is installed.
at chocolatey.infrastructure.app.commands.ChocolateyPinCommand.set_pin(IPackageManager packageManager, ChocolateyConfiguration config)
at chocolatey.infrastructure.app.runners.GenericRunner.run(ChocolateyConfiguration config, Container container, Boolean isConsole, Action`1 parseArgs)
at chocolatey.infrastructure.app.runners.ConsoleApplication.run(String[] args, ChocolateyConfiguration config, Container container)
at chocolatey.console.Program.Main(String[] args)
Exiting with 1
This was experienced with the package sql2012.nativeclient
When installing on server 2012 I get the following error "Microsoft SQL 2012 Native Client: A network error occured while attempting to read from the file: c:\users\administrator\appdata\local\temp\chocolatey\SQL2012.NativeClient\sqlncli.msi"
When I visit that folder the MSI appears to be called "SQL2012.NativeClientInstall.msi"
Renaming the file appears to be a standard operation of the Chocolatey framework as they are all like this.
This package is being installed as a dependency for sql2012.powershell.
This machine already has the SQL native client via a previous install of the SQL engine and SQL management studio.
So at the MSI level, here is what is happening:
When MSI does an official MSI Minor upgrade to an existing product, it finds the same product code installed on the machine. From the previous run it can tell the original file name that is registered in the MSI repository.
If the previous version was installed as an "MSI managed package", it then goes back to the new location the current version is being installed from and looks for the previous original name in that location.
It would take a long time to explain - but this is a way of preventing non-admin users from gaining MSI admin rights by upgrading an existing MSI on the system that was installed by an admin.
To eliminate these types of conflicts, you would want to not engage in a practice of renaming the MSI files.
A second, and even better thing to do, would be to have the chocolatey framework intelligently detect whenever an MSI is already installed and check versions. From there your options would be to [a] do the correct MSI command line to accomplish a minor upgrade (always uses "msiexec /fvomus .msi") [many packages aren't written correctly to accomplish a minor upgrade, [b] or better uninstall the previous version [works for imperfect MSIs and for major upgrades], [c] or at the chocolatey level, just mark the package as installed if it is the SAME or older version (doing this when the new MSI is truly new is probably not be what people expect of an installation framework that is supposed to automatically do everything correctly)
There are a few things we need to do:
Surrounding install and the helper functions.
In Powershell, some errors are not subject to try catch blocks, which
is indeed confusing when trying to assign those particular errors to
try/catch blocks. Ensure that all errors coming back from a script are
terminating, because they will cause powershell to exit with a non-zero
status no matter what, which choco will fail the installation of the
package on. This makes things less confusing as to why that is
happening.
The default one in the repository is for building source. If built in release mode, require a special switch to run --allow-unofficial-build or something like that.
When choco.exe detects that it is not using the official
publickeytoken, throw an error requiring an explicit override (this is
already overridden in debug builds). When AllowUnofficialBuild (--allow-unofficial-build) flag is
set to true, log a very important warning so that folks can receive
clues that the state of their system may be compromised.
When an upgrade fails, it will drag out the entire package folder with the new stuff over to lib-bad. But you still may have the old version installed.
Should the old version be put back?
Use Case:
Default, out of the box, when you do choco push you get a warning about missing source
As a User, I want to be able to specify default source, so I don't have to always do choco push -source http://chocolatey.org/
Official docs http://docs.travis-ci.com/user/languages/csharp/
Some references that are likely outdated (but might prove helpful):
Since it is still experimental, turn it off for now and allow explicit opt-in.
Thought this required us to flip over to internal posh components, but it only required a simple change away from createnowindow.
Currently the output for all versions shows up correctly, but it doesn't use all versions to detect against the registry managed programs that choco has installed for all versions of a package.
PS C:\code\temp> choco list -lap
Chocolatey v0.0.1.0
chocolatey 0.0.1
ruby 1.8.7.37402
ruby 1.9.3.55100
ruby 2.0.0.59800
ruby 2.1.5
2 packages installed.
7-Zip 9.22 (x64 edition)|9.22.00.0
Bitvise SSH Server 5.60 (remove only)|
Git version 1.8.3-preview20130601|1.8.3-preview20130601
Notepad++|6.4.2
Oracle VM VirtualBox Guest Additions 4.3.12|4.3.12.0
Ruby 1.9.3-p551|1.9.3-p551
Ruby 2.0.0-p598-x64|2.0.0-p598
Ruby 2.1.5-p273-x64|2.1.5-p273
8 applications not managed with Chocolatey.should be
PS C:\code\temp> choco list -lap
Chocolatey v0.0.1.0
chocolatey 0.0.1
ruby 1.8.7.37402
ruby 1.9.3.55100
ruby 2.0.0.59800
ruby 2.1.5
2 packages installed.
7-Zip 9.22 (x64 edition)|9.22.00.0
Bitvise SSH Server 5.60 (remove only)|
Git version 1.8.3-preview20130601|1.8.3-preview20130601
Notepad++|6.4.2
Oracle VM VirtualBox Guest Additions 4.3.12|4.3.12.0
5 applications not managed with Chocolatey.In addition, I've noticed it overwrites the log file as well. Let's fix that up.
Related to #7
For packages that have requireLicenseAcceptance set to true, we should pull and be able to print the license for the user to explicitly approve (unless they explicitly use -y or --accept-license).
Having MSI verbose logging can be very handy for packages. Many EXE based package run one or more MSIs - so having the logging can help diagnose challenging install problems.
The best approach is to backup the contents of the below registry key and then put in the below and then set it back to the previous settings when done.
The "DisableLoggingFromPackage" prevents a package's internal logging settings from overriding and making the logging less than full verbose.
The "Debug" setting shows the exact command line the MSI was called with (for example - from a setup.exe wrapper).
If no Installer policies are currently set, the entire "Installer" key level will be absent.
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Debug"=dword:00000007
"Logging"="xvoicewarmup"
"DisableLoggingFromPackage"=dword:00000001
Whether or not the powershell ran. Sometimes the cleanup performed by a chocolateyUninstall may not also include the uninstall of a file and sometimes it may not do it quite right.
Added this to track the state of a current request:
Low priority.
And display them to user.
Description helpfully provided by @teknowledgist below
I would love to have a "universal" (i.e. not dependent on the package maintainer) option to prevent/remove a desktop icon. This would need to be an attempt, but I suspect it could be successful most of the time.
Reason
Some installers have a switch to prevent desktop icons, and for those, the installing user can pass those through to the installer via --installarguments. Some package maintainers can/will included code to handle -packageparameters that will allow the package to deal with unwanted icons, but most maintainers do not. Some packages actually add an icon when the installer does not. It is entirely the maintainer's choice, and often out of the control of the installer.
Chocolatey installs are often scripted, and while the scripter could create custom code to manage the icons for each package install, it would be much nicer and more efficient to simply add a switch to the choco install call.
Issue
Identifying which icons to remove.
Mitigation
The most likely successful process for doing this is to track all the shortcut icons before the install, let the install finish, and then remove the new shortcut icons. Then the issue is reduced to determining which icons were dropped on the desktop due to the package as opposed to placed there by a user during the install or by another simultaneous install or process. Further reductions to the risk of false positives:
The switch should have a value (defaulting to ".*") that can be used as a regex match for icon names. That will give the (obviously knowledgeable) installing user fine-tuned control over the icons that are removed. If a value is provided, it should override other checks.
It would be highly unusual for an installer to place icons in both the CommonDesktopDirectory and the current user's desktop. If new icons are in both locations, only delete those from the common desktop.
Check that the target for each new icon is a subdirectory of the install location before deleting. For package installs for which the install location is not known, attempt a regex match of the $env:ChocolateyPackageName or the SoftwareName to the icon names.
That will be used when reviewing/accepting PR's, as well as what should be followed by core committers.
Choco seems to want a confirmation for each dependency. It would be helpful to have an option on each prompt that says "Confirm all subsequent dependencies for package x". Would be helpful to have this option on every dependency confirm prompt.
Similar to #52
If a shim is removed from the bin folder, there is no way to regenerate the shims without reinstalling the package.
That there is a method to regenerate missing shims, considering the exclusions for shim generation that are part of the package (dummy.exe.ignore).
N/A
N/A
N/A
Once created, update the contributing.md file.
C:\Windows\system32>choco uninstall ChocolateyGUI
Chocolatey (v0.9.8.32) is uninstalling ChocolateyGUI...
Uninstalling from folder C:\ProgramData\chocolatey\lib\ChocolateyGUI.0.11.4
Get-ItemProperty : Cannot find path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVe
rsion\Installer\UserData\S-1-5-18\Products\InstallProperties' because it does n
ot exist.
At C:\ProgramData\chocolatey\lib\ChocolateyGUI.0.11.4\tools\chocolateyUninstall
.ps1:9 char:16
$properties = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVe
+ CategoryInfo : ObjectNotFound: (HKLM:\SOFTWARE\...stallProperti
es:String) [Get-ItemProperty], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetIt
emPropertyCommand
ChocolateyGUI has finished successfully! The chocolatey gods have answered your
request!
C:\Windows\system32>choco uninstall ChocolateyGUI
Chocolatey (v0.9.8.32) is uninstalling ChocolateyGUI...
Uninstalling from folder C:\ProgramData\chocolatey\lib\ChocolateyGUI.
get-childitem : Cannot find path 'C:\ProgramData\chocolatey\lib\ChocolateyGUI.'
because it does not exist.
At C:\ProgramData\chocolatey\chocolateyinstall\functions\Get-ChocolateyBins.ps1
:17 char:16
+ $files = get-childitem $packageFolder -include *.exe -recurse
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\ProgramData\...\ChocolateyGU
I.:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetCh
ildItemCommand
Remove-Item : Cannot find path 'C:\ProgramData\chocolatey\lib\ChocolateyGUI.' b
ecause it does not exist.
At C:\ProgramData\chocolatey\chocolateyinstall\functions\Chocolatey-Uninstall.p
s1:33 char:7
+ Remove-Item -Recurse -Force $packageFolder
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\ProgramData\...\ChocolateyGU
I.:String) [Remove-Item], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.Remov
eItemCommand
C:\Windows\system32>
Be able to suppress upgrades
http://en.wikipedia.org/wiki/Package_management_system#Upgrade_suppression
Copied from chocolatey-archive/chocolatey#5
Allow interaction with features in the configuration with a feature command.
I don't want packages to change my PATH.
Packages can change the PATH environment variable that may cause issues for some users. We should provide a way to disable this.
There are three ways that installing a Chocolatey package can change the path:
Install-ChocolateyPath.disablePATHChanges.If we add this, it should be controlled with a switch and a feature.
N/A
Currently choco will throw an error if there is not an installed package as it does not perform the same as an install. The older behavior was to install if it wasn't there.
Say you have two ruby portables installed. You want to switch back and forth on the shims.
This is similar to regenerating shims
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.