I want to know about how can we get to know what parameters we can pass during a package installation using chocolatey like can we pass username,password and port during postgres installation from chocolatey repository.
So when you create a package for something like postgresql, you can use both install arguments[1] and package parameters[2]. Note that the package parameters has you add those params to the description[3].
If you are talking about existing packages from the community package repository, then you can pass install arguments directly to the installer if it is an installer package. You need to know what native switches the underlying installer supports. Those are transparent to packaging as long as they are calling choco functions. If the package has package parameters, you will find those listed in the description on the package page[3].
The nature of software installers in the Windows ecosystem is such that each piece of software is a special snowflake. Installer packages (packages that manage to the native software installers and Programs and Features), you can only go so much further than the limitations of whatever installer was used.
If an existing package you find could support some certain package params, reach out to the maintainers and file a ticket on their package source code (likely on GitHub). If you have the ability, provide a pull request with the fixes as well. That will go quite far in getting to what you need. HTH
[1] https://chocolatey.org/docs/commands-reference, see install, upgrade, and uninstall.
[2] https://chocolatey.org/docs/how-to-parse-package-parameters-argument
[3] https://chocolatey.org/docs/how-to-parse-package-parameters-argument#step-2---add-package-parameters-to-the-description
Just open up chocolatey "repo" and find the package. It is usually describing how to install it properly.
Alternatively you can examine the powershell installer file that comes with the package. From the code you can derive what you can pass to the choco install
Related
I recently set up a new machine and installed/enabled chocolatey. As far as I can remember I was able to call a package via powershell based on the package name. For instance, if I wanted to install mongodb, I used to type choco install mongodb - and was able to call the mongo client by simply typing mongo in the powershell console. Is there a way to see if something is bound to a specific shim ? or is there an option to enable it?
I don't think there is a way to match packages with shims, but you can check the executable a shim points to, along with general information about it and what would happen if you run the shim:
shimname.exe --shimgen-noop
I tried crafting a command to check all the shims in the $env:ChocolateyInstall\bin directory, but there's no guarantee that executables there are going to be a shim. I tried filtering out the known Chocolatey executables as well, but some packages (like putty) drop their real executables right in the bin folder, and won't respond to the shim parameters like you'd expect.
Looking at the Install-BinFile cmdlet, it doesn't look like Chocolatey provides a way to track shims at all as it doesn't even do this itself. I think it uses the same logic to track automatically generated shims at package uninstall time, but any shims explicitly created with Install-BinFile also need to have Uninstall-BinFile called in the associated chocolateyUninstall.ps1 script or the shim won't be removed at package uninstall time.
Short of crawling the $env:ChocolateyInstall\lib\packageName directory for potential automatic shim names, or the chocolateyInstall.ps1/chocolateyUninstall.ps1 scripts for explicit shims, you're not going to be able to match a shim to a package.
After I install a package in powershell by using
"choco install $package" where package is taken from a config file and would look like "WinRar" so I would be doing choco install WinRar, how do i get the exact path this package was just installed to?
For example when I am installing PhantomJS using this, it gets installed to C:\ProgramData\chocolatey\lib\PhantomJS\tools\phantomjs-2.1.1-windows and I as the developer know that, but since I need to add this to the env path, depending on which version the install command installs, the path will be different. I need to get the exact path so i can set the environmental variable to right place.
PhantomJS is just one example, but a lot of packages get installed into directories where their version is apart of the path and getting the path from the powershell install scripts would really be helpful.
Is there anything like this available for the package manager? I assume figuring out where the package just got installed to should be possible because I see it displayed on my terminal window, just don't know how to access it in powershell.
Thanks.
Currently there is not a way, but there is a thought to maybe provide back a list of package results with that information (along with more). That is still in a feature request so look for it to be developed in the coming months.
You could parse the Chocolatey output to determine where Chocolatey saw things get installed and we are working to make that detection even better.
I have a few powershell commands in a script that I want to distribute to everyone on my team. This script may be updated and I would want an easy way for my team to update this script as well. Someone suggested Chocolatey which I have never used before. I found the following in the Chocolatey.org FAQ:
"What kind of package types does Chocolatey support?
Binary Packages – Installable/portable applications – This is 98% of the Chocolatey packages – most are pointers to the real deal native installers and/or zipped software.
PowerShell Command Packages – Packages that have the suffix .powershell will install PowerShell scripts as commands for you to call from anywhere.
Development Packages – Packages that have the suffix .dev. For instance dropkick.dev.
Coming soon – Virtual Packages – Packages that are like a category, and you just want one package from that category. Read more ..."
Does anyone have an example of using chocolatey to install a powershell script to the Path so that the commands in it can be executed from anyway on the machine? I am unable to find an example of how to do this online.
If this is an inappropriate use of chocolatey, please let me know and feel free to recommend an alternate solution.
Thank you very much for your time. Please let me know if I am being unclear or if you have any questions for me?
Look at the PowerShell Function Reference, which has all of the different functions you can call. Then take a look, specifically, at the Install-ChocolateyPowershellCommand helper. Here's an example of a package that installs a powershell script as a command (source).
How do I tell DSC that a resource/module from OneGet/Package Management needs installing, first?
Do I just use a Script Resource and configure PowerShellGet and then manually call Install-Module?
you could use powershell remoting and install the modules beforehand.
or
you could use a script resource
or
use this module from github
powershellmodule
if you have a pull server you can use the github module centrally otherwise when using push you will have to copy the github module referenced above to all target systems but then it is a one time process at least for installing modules from the gallery.
You can use the packagemanagement provider resource available here in order to install the required packages https://github.com/PowerShell/PackageManagementProviderResource
I was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.