No option to provide installation parameters?

[pfmoore]

If I want to install from a MSI, for example, I may well want to specify parameters such as which features to include (ADDLOCAL=xx,yy,zz). Or which directory to install to (DESTDIR). There doesn't seem to be a way of doing that.

[fearthecowboy]

Yeah, I half implemented that -- there is a -AdditionalArguments option, but it looks like I didn't hook the use of that up yet.

I'll try to get that done in the next week or two.

[robmen]

What options are there in the package? There is only one Feature and the install location is not configurable because PowerShell... right?

[fearthecowboy]

I beleive He's talking about OneGet installing msi packages

[robmen]

Oh, heh, heh. My bad. When you work on the hammer...

[pfmoore]

lol. Yes, I'm talking about something like Install-Package Foo -Destination D:\Apps -Features Extra1,Extra2 -Exclude FeatureIDontWant.

Ideally, this should be possible for providers other than MSI (although how "features" map in that case would be up to the provider).

To give a typical example, I usually install Python in C:\Apps\PythonXY, omit the "Register Extensions" feature and include the "Add to PATH" feature.

[fearthecowboy]

Well, the notion is available for all providers--each provider can implement any number of dynamic options, and therefore take (or require) what ever extra options they'd like.

In this case, the MSI sports an -AdditionalArguments parameter, but I foolishly haven't finished implementing it yet.

[pfmoore]

OK, that would do it - although I do think that -Destination, -Include and -Exclude are common enough concepts that they should probably be supported in the base command (otherwise, you need to know what provider everything is coming from before you can do anything other than a default install).

[eosfor]

Sorry to interrupt you guys. Actually there is a good powershell module for MSI here https://psmsi.codeplex.com/. It is really cool and i was using it for a while. Sorry for giving you the advice, but perhaps it would be possible to reuse it in OneGet. I hope it may save some time for you. Unfortunately i'm systems engineer and i can not do it myself )

---

С уважением, Андрей Вернигора MCSA, MCDBA, MCSE, MCT

2015-01-20 21:51 GMT+03:00 Paul Moore notifications@github.com:

OK, that would do it - although I do think that -Destination, -Include and -Exclude are common enough concepts that they should probably be supported in the base command (otherwise, you need to know what provider everything is coming from before you can do anything other than a default install).

— Reply to this email directly or view it on GitHub https://github.com/OneGet/oneget/issues/95#issuecomment-70709445.

[fearthecowboy]

Yeah, I'm well aware of psmsi -- it's a rather nice little PS module that exposes pretty much everything you'd want from MSI :)... I've talked to the author (he works for MS too) and we'll look into bringing some stuff along from there.

[heaths]

That would be me. I was looking at this too since I just tried to install the 'git' module from the Chocolatey package provider and found it didn't update my PATH automatically. Seems I have to pass /GitOnlyOnPath. So does supplying additional arguments become a provider capability, then? Would seem to make sense but I'm still groking the current code. What is unfortunate is that all these providers have different ways to pass arbitrary arguments. MSI, for example, is limited to PROPERTY=VALUE while Chocolatey is whatever the package author supports. Same with the ARP provider.

[pfmoore]

Could OneGet not provide a unified approach for certain "common" parameters (destination dir, what features to install) and an escape hatch to provide anything the provider allows? Providers could decide not to support the standard parameters if they don't have the means to, but it would exert a certain pressure on providers to unify the package-dependent mess that is the current situation for controlling silent installs...

[fearthecowboy]

The idea is to over the next while, distill out the more 'common' parameters and consolidate those into a set of "if-you-handle-this-sort-of-thing-then-please-do-it-this-way" guidelines.

As we develop the providers, I think this list of common parameters will become more evident.

[heaths]

@fearthecowboy, when do you think you can push an early form of what you have for -AdditionalArguments (PS: I'd AliasAttribute that as args for consistency with PS)?

I do see the MsiProvider yields the AdditionalArguments command line arguments but with no way to alias. What seems better - and would accomplish both - is that this is a provider feature. After all, MSI, NuGet / Chocolatey, and even ARP (possible - that's really a wild west of sorts) can all take additional arguments. Any objection to exposing this as such?

[fearthecowboy]

I've been thinking this thru a bit, and I'm not entirely sure I have the ultimate answer yet.

:warning: warning: rambling thoughts ahead

Right now, it's possible for Package Providers to specify any number of dynamic options in one of four categories (source, provider, package, and install ) -- those four broad categories are mapped to each of the cmdlets in a variety of overlapping sets.

It would be most ideal if, when installing a package, the provider could also expose any custom parameters that the package itself may take, rather that just having an "additional arguments" bucket to pass thru the rest of the arguments thru.

The trouble with that notion, is that I'd either (a) have to make the cmdlets (well, at least install/uninstall) expose a parameter with ValueFromRemainingArguments=true and then process the unknown ones, or (b) during tab-expansion, examine the command line, see if there is a package involved, and then query the package provider for package-specific parameters.

Unfortunately, that's not very 'discoverable' .

Hmm. It just occurred to me that there is a third option.

I could just allow a provider the option to say "yeah, pass me any unknown parameters" for a given call. Then stuff like -property value could be handled more naturally, instead of -additionalarguments @{property=value}

We could also have the package provider fill in some additional metadata in the SoftwareIdentity that gets returned from find operations and include the optional parameters that could be surfaced.

PS > (find-package SomePackage).AdditionalParameters 

{someproperty, someotherproperty, thirdproperty }

Hmm. Perhaps we should discuss this at Friday's meeting.

[guitarrapc]

Hi, how's it going? -AddionalParameters seems not working even on Windows 10.

Install-Package -AdditionalArguments @{Name="zoomit"; Source="Chocolatey"}

Just as @pfmoore memtioned, there are many cases to select where to install. Many package management system support install path selection, like yum in "installroot", PakcageManagement(OneGet) would prefer to support this. https://github.com/OneGet/oneget/issues/95#issue-54905304

Or should we make custom Cmdlet...?

[Jaykul]

But @guitarrapc those are not even "additional" arguments -- those are built-in arguments. You just have to call:

Install-Package zoomit -Source Chocolatey

The provider (chocolatey, in this case) can expose additional dynamic parameters ... but it's up to the provider to do so (and in the case of chocolatey, to pass those parameters on to the installer)

[guitarrapc]

@Jaykul You are correct, and agree with you. It's difficult problem to expose and offer install location when using Install-Package..

However many users will expect to specify install location, as currently I got requests from my co-workers:)

Don't you think it nice if both Provider and OneGet provides any parameter to select install location? So users can be select where to install package with OneGet. Image something like:

Install-Package zoomit -Source Chocolatey -InstallRoot D:\Apps

The problem is not only Provider implementation. But also OneGet need to pass through -InstallRoot to the provider.

[Jaykul]

My point is that OneGet already has the feature. Providers can expose any dynamic parameters they want to, on top of the built-in parameters for Install-Package. It's purely a provider issue.

Frankly, in the world of package management, I think it's crazy to consider letting people decide where to install things. The package manager will put the bytes on the disk, and put shortcuts in your menu and executables in your path. Pick ONE PLACE, and let all the packages go there. The end.

Of course, Chocolatey isn't really a package manager, it's just an installation automation tool ;-)

[bitcrazed]

Any progress on this? I, for example, would like to be able to pass additional parameters to the git.install package to instruct it to use /GitAndUnixToolsOnPath.

[quoctruong]

@bitcrazed You can use DynamicParameters to pass additional parameters to the provider. For example, NuGetProvider has a Destination dynamic parameter when used with Install-Package.

[Jaykul]

This ticket should be closed. The feature is there in OneGet. It's now a provider feature that is being asked for.

[pfmoore]

Not true - the option I was asking for was a unified means to specify an install destination and select options, not a way to pass through provider-specific parameters (in a provider-specific format) to do the same.

Understood that this may need a means for providers to say how OneGet passes these specific options on to the provider, but that's an implementation detail (which may have ackward compatibility implications, certainly).

If I need to know the provider before I can specify the install parameters, that somewhat defeats the object of having a unified interface, IMO...

[Jaykul]

There's no way that OneGet can force a -InstallRoot type of parameter on providers, because many providers will not (and should not) provide that as a feature.

However, it's common enough on development package managers that I think it would be worth exposing it as an optional parameter and dictating a single common name for it so that everyone can use the same parameter name and simply implement the API for it to show they support it.

However ... that is not what you guys are asking for.

We have to differentiate between software packages (applications, such as those installed by apt-get, yum, chocolatey, etc) and development packages (modules and libraries, such as those installed by CPAN, PPM, NuGet, Bower, npm, etc).

Development Packages

The idea of an install root location is something which is common to development packages because packages are usually installed per-project, and go in a particular folder structure in that project. That is, you must specify the project root in order to get the packages installed correctly, and the root of the project is the same across bower, npm, nuget, etc.

Setting up multiple InstallRoots sets up multiple dependency trees, and package managers which support InstallRoot have to track dependencies separately for each root.

Software Packages

Specifying install locations for software packages is a completely different problem. The "root" is generally C:\Program Files\ and it's defined in the environment and should not be changed. Changing the install root is absolutely not a common requirement in the world of software packages -- it is contraindicated by the need to manage binary dependencies and the desire to keep duplication down. Predictable install locations are required.

Take a look at the PowerShell PSModule package manager as an example. It allows you to install into one of two root locations (per-user and per-machine), and it determines the actual install location based on the package.

Software package managers don't generally even offer that much configuration (look at apt-get, for instance), and simply require you to be an administrator because they install everything in the "correct" FileSystem Hierarchy Standard location.

I could go on and on about how things should be, but the point is:

MSI/Setup.exe providers are a unique and special problem.

I could just say that Chocolatey is unique, but there are a few other package managers out there which attempt to ease the transition to package management by supporting legacy installers. For the sake of convenience, let's just refer to them as Chocolike.

Chocolike providers have two install locations: the cache where they unpack the packages (generally, a standard location per machine or per user), and the ultimate location where the actual wrapped installer installs to when you execute it.

All of the people in this thread so far have been looking to either change the ultimate install location with a Chocolike provider, or to pass arbitrary parameters to a specific installer that is inside the package. This is a completely different problem which (for the record, @pfmoore) if far worse than just needing to know the provider.

That is, when you asked about /GitAndUnixToolsOnPath you are not only asking about a specific provider, you are asking about the ugly internals of a specific package for a produce on that particular provider.

• You have to know the provider
• You have to know how the product is packaged on that provider
• You have to know that there are options you need to specify
• The installer has to support those options
• The package has to support passing parameters to the installer

Bottom line: the provider has to support passing arbitrary parameters to the ... package?

In my opinion...

You should not be able to do that.

The fact that this option is there is the result of indecision on the part of the packager and developers. Engineers build ugly products.

Packages shouldn't have their own options, because there's no way to know what they are!

Knowing and using special options for a specific package runs counter to the whole notion of package management. What you are trying to do is get Install-Package to result in this very specific call:

choco install git --params="/GitAndUnixToolsOnPath /NoAutoCrlf" -y

• That params string is unique to that package.
• You needed to know to use --params and not --installargs
• The idea of parameters is unique to Chocolike providers which assume there's actually an installer inside the package
• The difference between params and installargs is unique to Chocolatey specifically. Chocolatey packages have scripts which can have their own arbitrary parameters in addition to the parameters which will be passed to an installer.

There is nothing common to implement here.

What you need is a Dynamic params parameter and installargs from the Chocolatey provider.

The right way would have been ...

For what it's worth, the correct way for things like this to work, in my opinion.

• The package should install to a specific well-known location
• The package should specify the tools are command-line tools
• The provider should ensure that command-line tools are on to the PATH.
• If you need to modify which folder(s) are on the path, you would do that as part of Configuration
• Configuration (particularly the /NoAutoCrLF option) would be done after install -- perhaps via DSC, Chef, Puppet, etc., or perhaps via a simple command to edit the file in it's well-known location.

[pfmoore]

Hmm... That's a lot to take in (and I don't follow it all). As the person who originally raised the issue, let me explain my position.

I've no background in DSC/Chef/Puppet, or in NuGet or .net development. My interest in OneGet is purely as a package installer - something that will let me do a command line install of programs such as Python, Git, Mercurial, Notepad++, ... I've previously tried chocolatey, but dislike it - because it's hard to understand what package is what (which of the plethora of Python packages do I want?) and because it imposes its own installation model (maybe only for some packages, but I mean the whole "shim" business). That's beside the point, though - let's just stipulate that I've tried Chocolatey and it doesn't do what I want, and I was hoping OneGet would be a better alternative.

So OneGet for me is a way to simply install programs. It gives me a unified way of doing so, without needing to hunt out download URLs, work out the correct invocation to get silent (or command line) installs, etc etc. That ideal is largely theoretical at the moment, because there are basically none of the packages I want to install available in the default repositories at the moment, but hopefully that will change.

But - and this is my issue - I do sometimes want to change certain aspects of installs. These are typically only the two areas I mentioned in my original report - changing the default install location (for example, I install my Python versions in C:\Apps\PythonXY, so they don't all clutter the root directory) and changing the "optional features" selected (for example, I deselect the Explorer integration from Mercurial). Ideally, I'd like these options (which are common to pretty much any application installer I've ever seen) to be exposed in the same unified way that OneGet already unifies the process of locating packages and running the installer in silent/command-line mode.

Maybe I've misunderstood what OneGet is for. Maybe my expected usage will never happen, and OneGet is only ever likely to be used for PowerShell modules and DSC modules. But my expectations are driven by what I've seen documented as the goal for OneGet, so if I am misunderstanding, then maybe it's a documentation issue rather than a feature request.

Maybe I should ignore OneGet until tools like Python, Mercurial, Git, etc are available for native install (i.e. not the Chocolatey versions - sorry if that is controversial for Chocolatey fans here) from OneGet, so that I have real use cases rather than just expectations.

Anyway, I just wanted to clarify what this request was about, as the discussion seems to have drifted a long way from what I was asking.

[Jaykul]

OneGet is not a package manager. It's a manager for package managers. The only thing that OneGet itself installs is package manager providers that are in the bootstrap list.

All of the *-Package commands basically pass options through to the relevant package providers.

Some package managers do install programs, but so far Chocolatey is the only one on the bootstrap list that does (there are a couple of others which are trying to get on). In other words, currently, if you use OneGet to install an app, OneGet is using Chocolatey.

My point in the previous post is that customizing installation of applications by passing parameters to them is a feature that is relatively unique to Chocolatey -- so it's not worth creating a "universal" parameter. OneGet already allows providers to expose any options which are specific to them, so Chocolatey can already expose --params and --installargs ...

However, if you've already determined you're not happy with Chocolatey's options, you're probably out of luck... at least for now.

[pfmoore]

Ah, OK. Understood. Thanks for the clarification. Doesn't the MSI provider allow customization via parameters, though?

Are there any good documents I should read to understand all of this better? One issue I have is that most of the time I have to experiment with this stuff is on a Win7 machine that for some reason doesn't have OneGet when I install WMF 5.0 (see https://github.com/OneGet/oneget/issues/148 for details) so I can't easily try things out (my ultimate taget environment is Win10, but my access to the Win10 machine I'd use is limited currently...)

Anyway, you've answered my question so I think this issue can be closed now.

[Jaykul]

That's a great question -- I'm really not sure what the MSI provider can do (if anything) ;-)

[ferventcoder]

@Jaykul I'm late on seeing this, but I wanted to address a couple of points.

The right way would have been ...

For what it's worth, the correct way for things like this to work, in my opinion.

• The package should install to a specific well-known location
• The package should specify the tools are command-line tools
• The provider should ensure that command-line tools are on to the PATH.
• If you need to modify which folder(s) are on the path, you would do that as part of Configuration
• Configuration (particularly the /NoAutoCrLF option) would be done after install -- perhaps via DSC, Chef, Puppet, etc., or perhaps via a simple command to edit the file in it's well-known location.

I'm in complete agreement with this sentiment. I would even change your heading to "The recommended way with Chocolatey is...". Chocolatey supports this idea completely. I will say as well, there are certain things we are not able to easily do on the community feed as folks take issue if we do much more than the installer does with the package.

That said, we _ALSO_ support package parameters. And that is a very important distinction.

The fact that this option is there is the result of indecision on the part of the packager and developers.

This statement is almost completely incorrect (depends on what you mean by "developers").

• Package parameters require a sensible default already specified in the package.
• Package parameters allow a consumer to switch the defaults. Not everyone likes a black car.
• Package parameters are about something related to packaging or fill a gap that installer arguments cannot.

This means that package parameters are really about convention over configuration and the option was very intentional for the Chocolatey developers (although I assume you meant by "indecision on the part of the packager and developers", you meant the developers of the installer files/MSIs).

For the options you pass to Git for example:

1. You _could_ use install arguments to do those, but you are also expected to know how to pass those to InnoSetup in this case.
2. Except that with the Git installer, there are no silent arguments you can pass to InnoSetup to allow the behaviors defined as package parameters.

I'll say it again for effect, there is _no_ silent install argument you can pass to the Git installer that will allow putting git and the unix tools directories on the path. That only exists in the user interface when installing Git. The fact that a Chocolatey package can offer that ability is not an indecision on the part of the package maintainer (me) nor the Chocolatey developers (also includes me). In fact quite the opposite.

Install Arguments are for the Native Installer / Package Parameters are for the Package

The most important thing to understand is that Install Arguments are transparent to package maintainers. Thus they are passed right through to the native installer and never seen in the package. Package parameters are for allowing changing _default_ behaviors of the package itself or behaviors of the native installer that cannot be changed with install arguments.

Look, software installers are like the wild west and in many cases are quite messy. Couple that with everyone wanting to do custom things or not having the same ideas about where things go, it makes things that much more messy. Chocolatey exists (with those options) to corral that chaos into a single unifying interface. We are making that much smoother every day, like the addition of the ubiquitous installation directory switch coming as a preview in 0.9.10.

[Jaykul]

@ferventcoder I have no argument with Chocolatey providing "Installer Arguments" and "Package Parameters" -- when software engineers build installers with so many options in the installer, Chocolatey almost has to expose them, at least optionally, because of it's practical decision to support automation of the installers rather than requiring the original software author to repackage for Chocolatey.

My argument is essentially that the Chocolatey provider needs to expose both of those features as dynamic parameters -- they aren't "common" to the underlying notion of a "package installer," they are specific to the fact that Chocolatey has packages wrapped around "native" installers.

[ferventcoder]

:+1: