New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No option to provide installation parameters? #95

Closed
pfmoore opened this Issue Jan 20, 2015 · 30 comments

Comments

Projects
None yet
10 participants
@pfmoore

pfmoore commented Jan 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy Jan 20, 2015

Contributor

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.

Contributor

fearthecowboy commented Jan 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@robmen

robmen Jan 20, 2015

Contributor

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

Contributor

robmen commented Jan 20, 2015

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

@fearthecowboy

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy Jan 20, 2015

Contributor

I beleive He's talking about OneGet installing msi packages

Contributor

fearthecowboy commented Jan 20, 2015

I beleive He's talking about OneGet installing msi packages

@robmen

This comment has been minimized.

Show comment
Hide comment
@robmen

robmen Jan 20, 2015

Contributor

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

Contributor

robmen commented Jan 20, 2015

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

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Jan 20, 2015

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.

pfmoore commented Jan 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy Jan 20, 2015

Contributor

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.

Contributor

fearthecowboy commented Jan 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Jan 20, 2015

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).

pfmoore commented Jan 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@eosfor

eosfor Jan 20, 2015

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
#95 (comment).

eosfor commented Jan 20, 2015

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
#95 (comment).

@fearthecowboy

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy Jan 20, 2015

Contributor

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.

Contributor

fearthecowboy commented Jan 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Jan 24, 2015

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.

heaths commented Jan 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Jan 24, 2015

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...

pfmoore commented Jan 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy Jan 24, 2015

Contributor

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.

Contributor

fearthecowboy commented Jan 24, 2015

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

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Jan 25, 2015

@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?

heaths commented Jan 25, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@fearthecowboy

fearthecowboy Jan 26, 2015

Contributor

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

⚠️ 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.

Contributor

fearthecowboy commented Jan 26, 2015

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

⚠️ 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

This comment has been minimized.

Show comment
Hide comment
@guitarrapc

guitarrapc Aug 26, 2015

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.
#95 (comment)

Or should we make custom Cmdlet...?

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.
#95 (comment)

Or should we make custom Cmdlet...?

@Jaykul

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Aug 26, 2015

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)

Jaykul commented Aug 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@guitarrapc

guitarrapc Sep 2, 2015

@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 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

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Sep 4, 2015

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 ;-)

Jaykul commented Sep 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@bitcrazed

bitcrazed Oct 24, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@quoctruong

quoctruong Oct 26, 2015

@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.

@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 comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Oct 27, 2015

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

Jaykul commented Oct 27, 2015

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

@pfmoore

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 27, 2015

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...

pfmoore commented Oct 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Oct 27, 2015

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.

Jaykul commented Oct 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 27, 2015

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.

pfmoore commented Oct 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Oct 28, 2015

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.

Jaykul commented Oct 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Oct 29, 2015

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 #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.

pfmoore commented Oct 29, 2015

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 #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.

@pfmoore pfmoore closed this Oct 29, 2015

@Jaykul

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Oct 29, 2015

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

Jaykul commented Oct 29, 2015

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

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder Feb 19, 2016

@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 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

This comment has been minimized.

Show comment
Hide comment
@Jaykul

Jaykul Feb 20, 2016

@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.

Jaykul commented Feb 20, 2016

@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

This comment has been minimized.

Show comment
Hide comment

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment