Support package specific parameters

[rismoney]

Imagine Exch2013:

Setup.exe [/Mode:] [/IAcceptExchangeServerLicenseTerms]
[/Roles:] [/InstallWindowsComponents]
[/OrganizationName:]
[/TargetDir:] [/SourceDir:]
[/UpdatesDir:]
[/DomainController:]
[/AnswerFile:] [/DoNotStartTransport] [/LegacyRoutingServer]
[/EnableErrorReporting] [/NoSelfSignedCertificates]
[/AddUmLanguagePack:]
[/RemoveUmLanguagePack:] [/NewProvisionedServer:]
[/RemoveProvisionedServer:] [/ExternalCASServerDomain:]
[/MdbName:] [/DbFilePath:]
[/LogFolderPath:] [/Upgrade]

I would like to cinst ExchangeServer -params and get this or get it by default if omitted if package developer requires it (vs use a default set). Can assist in path selections for most pkgs as well.

cinst ExchangeServer -param="/roles.." and then it becomes part of $silentargs. Thoughts on this functionality before I go to town?

[ferventcoder]

This already exists today? installargs - https://github.com/chocolatey/chocolatey/wiki/CommandsInstall

Is this not the same?

[rismoney]

oh snap. it does! good job!

maybe it needs refinement to provide a bit more user friendliness. Right now, is the end user supposed to just "guess" what the params are?

[ferventcoder]

Yes. This gives someone direct access to the native installer so they can pass their own arguments and even override the args going to it. It's really a power user feature b/c it puts you right against the metal.

[ferventcoder]

So you could be talking about something slightly different...

[rismoney]

It needs to be fixed for full functionality.

Cannot run say /? Because it won't cleanup, which we know about.

The Params should be at the discretion of the package creator, and they should publish a list. This way it doesn't need to execute the binary for help.

Params might also cross multiple helpers. I unzip a set of folders to Param1 then install chocolatey install to param2

[FunkMonkey]

+1

Common command-line parameters, like rismoney proposed, seem to be a much better approach than installArgs, as they are:

• more user-friendly
• more generalized (work with packages that use zips, installers, etc.)

I have already found some places, where i would have liked parameters to alter the package install behaviour, f. ex in the python package to choose the platform (in case you want to install 32bit python on a 64bit machine, which i had to for octopress to work). It could look like "cinst python -x86" (or with backslash, though i like the hyphen more).

This issue is also related to #133

[ferventcoder]

We've already talked about the -platform x86 switch - I think there is an enhancement listed for that (and if not, let's make sure it gets listed). :D

[FunkMonkey]

question is, whether chocolatey

a) just parses specific parameters like "-platform" and passes those on (while ignoring the rest) to the installer script
b) parses all parameters and passes them on as a list to the installer-script so that the package creators can customize the install-behaviour with their own parameters

are there any advantages to specific switches as in a) compared to giving installer scripts access to all parameters?

[rismoney]

say i install 2 msi's. i want to pass /qn to one and /quiet to another. then i want to install a zip.
the developer has to have control over what goes where.

in #160 I'd want in chocolateyrun.ps1 a function usage()

what cross my mind earlier is to make some sort of chocolatey DSL like pester (which i haven't looked at yet)

[ferventcoder]

-platform is for the utility function which the package dev has no access to. So the key is completely transparent to them.

[ferventcoder]

We need to get this in for the next version. Granted it will be rudimentary, but it is necessary for a recent package issue where the vendor wanted you to pass something or fail the package.

[ferventcoder]

How about choco something -params "@{bob=1;bill=2}"

[ferventcoder]

This is very naive as mentioned in the commit (no spaces and must be specified in EXACTLY the format shown). If you want to start playing with it though, it's in the just sent out prerelease.

cinst chocolatey -version 0.9.8.22-alpha1

[ferventcoder]

$env:chocolateyPackageParameters in the package....

[allensanborn]

It doesn't look like that will work.

The hashtable is getting cast to a string. So when you try to get it back out you just get System.Collections.Hashtable.

What are the limitations on using the $packageParameters variable in our install script? In my test package I'm getting the hashtable and the parameters that I sent in via cinst.

PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $testhash=@{name="value";name2="value2"}
PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $env:testhashenv = $testhash
PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $testhash

Name                           Value
----                           -----
name                           value
name2                          value2


PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $env:testhashenv
System.Collections.Hashtable
PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages>

[ferventcoder]

[hashtable]$var=$env:teshhashenv
Then call $var?

On Sunday, November 10, 2013, allensanborn wrote:

It doesn't look like that will work.

The hashtable is getting cast to a string. So when you try to get it back
out you just get System.Collections.Hashtable.

What are the limitations on using the $packageParameters variable in our
install script? In my test package I'm getting the hashtable and the
parameters that I sent in via cinst.

PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $testhash=@{name="value";name2="value2"}
PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $env:testhashenv = $testhash
PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $testhash

Name Value

---

name value
name2 value2

PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages> $env:testhashenv
System.Collections.Hashtable
PS C:\Users\allen\Documents\GitHub\Chocolatey-Packages>

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/159#issuecomment-28156258
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[rismoney]

no dice fellahs. env var's are string only.

ref:
http://stackoverflow.com/questions/13128284/using-non-string-as-env-variable

[ferventcoder]

Well that is easy enough to fix... ;)

[ferventcoder]

Here we go choco something -params 'value1=bob;value2=''with spaces''' - the two single quotes value2=''with spaces'' will be converted to value2="with spaces"