Chocolateygui: Allow for passing in package parameters / installer arguments (maybe other arguments directly to choco)

[ferventcoder]

It would be great to be able to pass through package parameters and installer arguments as part of installation. There are some folks out there who enjoy the UI but still want some of the customization of installed packages.

Other things to consider:

• Setting to force which architecture of a package is installed (x64, x86)
• Ability to select which version of a package is installed

Based on discussion during a Twitch session on 20th April 2020, the following things were discussed/mentioned regarding this topic (@AdmiringWorm @mkevenaar @mwallner @punker76)

• [x] Selected version should be the latest version available by default
• [ ] In order for this to work, we need a new release of Chocolatey.Lib
• [x] We should restrict the number of available package versions, perhaps 20 by default (but this should be configurable), with an option to load more results
• [ ] There should be a More .. option, or similar, next to the combobox for loading more package versions
• [x] Versions should be sorted from newest to oldest
• [ ] Perhaps provide the ability to allow a package version number to be entered directly into the box, but this should be validated before usage
• [ ] Would be could to have autocomplete/filtering on the combobox to make it easy to find a package version
• [x] There should be a checkbox to control whether pre-release package versions are included in the combobox
• [x] Would be nice to fetch the available package versions once the Advanced dialog is opened, with a loading indicator

In addition, we went through the available options/switches for the install command, and decided that the following should be available:

• Command Timeout
• Log File
• Version
• Pre-Release (could be set automatically, based on selected package version)
• Force x86
• Install Args
• Override Args
• Not Silent (we were undecided on this one)
• Package Parameters
• Args Global
• Params Global
• Allow Downgrade (could perhaps infer this, based on current state of system)
• SxS (we we undecided on this one)
• Ignore dependencies
• Force dependencies
• Skip PowerShell
• Checksums, and all related options - discussion to be had around this

Think that was everything that was discussed, but can add more

[RichiCoder1]

Yup, this has been asked before I believe. How would we surface this? Add an additional Install With... option or something that surfaces a text box for pasting in params?

[ferventcoder]

How would you see it? I like maybe having a hidden area at the bottom where this can be specified, and the user just clicks like a right arrow (that converts to a down arrow) to expose this section.

Kind of like summary and detail tags in html5.

[aadrian]

@RichiCoder1

How would we surface this? Add an additional Install With...

For simplicity this should be available only in the detail window, since only from there is visible that a package has parameters at all.

Ideally parameters would be parsed automatically and offered as UI options, but I'm not sure if there's a standard way to read those from package descriptors.

If it' possible, than a UI form could be generated from all those parameters. There are projects that do this already, e.g. http://ugui.io/

[paul-michalik]

What happened to this? Another (seemingly related) issue for which I haven't found an answer is the collaboration of chocolateyGUI with useRemeberedArgumentsForUpgrades feature. From what I can tell, the remembered arguments are ignored: observed with git.install, cmake.install and many other packages.

[ferventcoder]

What happened to this?

Hi @paul-michalik, note that the ticket is open and has no identified milestone. Currently it looks like we've given it some labels, so we've validated we want to do it. Then it goes into a prioritization schedule to determine "when" - that's a hard answer that has many variables (and projects) at play. That could be anywhere from a week to 2 years from now (just to give you a good expectation - we have a list and roadmap that goes out a few years to really give you an idea).

So we can actually document this somewhere, I'm going to spend a bit of extra time providing you a really good answer here.

Details

Ticket In Queue

So this ticket is in queue, validated that we'll do it. Here's how you can tell.

• Ticket is still open - ticket has not been closed as invalid, won't do, or duplicate
• Ticket has release determined or not based on milestone

Ticket at Release / Ready for Release

So when it has gone through the process, the ticket is updated and closed. If there is a milestone and it is closed, that is the release it is in. If that release has not happened yet, that means it is ready for release.

• Ticket is closed with milestone identified

Are You a Customer?

If you are commercial customer and you are wanting us to look at bumping prioritization of this, please indicate so here so we can look at where this could bump in priority. It should go without stating that we need to prioritize workload based on needs of folks who keep us in a job and critical needs ahead of features that may have workarounds.

Not A Customer, But Really Need This?

It is open source, ask us to tag it as "Up for Grabs", and you can contribute the work to make those changes in a pull request. That is the spirit of open source at it goes - folks using and benefiting on those things that are free that can't give back in the way of financial support might want to consider documentation, feature requests and bug tickets (and testing), and contributing back.

Create Another Ticket For Related Bug?

Another (seemingly related) issue for which I haven't found an answer is the collaboration of chocolateyGUI with useRemeberedArgumentsForUpgrades feature. From what I can tell, the remembered arguments are ignored: observed with git.install, cmake.install and many other packages.

This sounds like a bug. Possibly related to this. But also probably deserving of its own issue so that it can be tracked and fixed separately (maybe even sooner!).

[vertigo220]

To add to this, as mentioned in #526 the GUI should allow rolling back (rollback, downgrading, versioning) to a previous version. This can be done via the CLI with "choco list packagename --all" then an uninstall and an install of the desired version, but if the GUI provided a list of all versions and allowed you to click on one to install that version (uninstalling the current one as well, obviously), that would be really useful for when the need arises to do so.

[gep13]

Work has started on implementing this feature. I will update this issue as I have more information.

[gep13]

@AdmiringWorm @mkevenaar @mwallner @punker76 not sure if you will get a notification for the edit that I made to the first post in this issue, so thought I would follow up here.

I have updated the original post to include what was discussed on the twitch stream. Let me know if I have missed anything.

[gep13]

Adding in all the properties that I believe are required into the dialog results in the following:

Obviously, there are changes that can be made to optimize this layout, but just wanted to put this out, to get some feedback on how it should look.

@AdmiringWorm @mkevenaar @mwallner @punker76

[mwallner]

Adding in all the properties that I believe are required into the dialog results in the following:

:scream:

Obviously, there are changes that can be made to optimize this layout, but just wanted to put this out, to get some feedback on how it should look.

I think it's nice to have all options there, yet I'd prefer to have them grouped and maybe "collapsed" by default...
I've got no clue how this could be done in WPF, but I think something like this "accordion" would be a good option: https://getbootstrap.com/docs/4.0/components/collapse/#accordion-example :sweat_smile:

Groups titles/types could be:

• checksum - Ignore Checksum / Allow Empty / Require / Checksum Strings
• dependencies - Ignore / Force
• debugging - log file / debug switch / verbose switch
• ...

[gep13]

What options, if any, should be shown by default?

[mkevenaar]

I think --version and --params are the ones I use mostly. -ia is one that could be added by default as well. Rest could be collapsed like @mwallner suggested.

[AdmiringWorm]

I agree with @mkevenaar on this, the Version, Package Parameters and Install Arguments are the ones that should be shown by default.

The rest could be either grouped in a single Expander or several expanders.

Some of the arguments should probably only be available in some instances, like Allow multiple versions only being useful if a package is installed.

PreRelease and allow downgrade should probably be implied depending on the version selected.

Regarding the UI, maybe changing the checkboxes to a ToggleSwitch would look a little better?
Probably would need a tooltip for the different options as well.

Btw, what are the Apply Install Arguments to and Apply Package Parameters for?
Can't say I have seen any arguments on choco.exe that those options would map to.

[gep13]

@AdmiringWorm said...
Btw, what are the Apply Install Arguments to and Apply Package Parameters for?
Can't say I have seen any arguments on choco.exe that those options would map to.

This is these options. I used the full name for them.

[gep13]

@AdmiringWorm said...
Regarding the UI, maybe changing the checkboxes to a ToggleSwitch would look a little better?

I had the same thought, as it would be more consistent with what is in the current Settings screen. I will have a stab at this, and post an image at some point.

[gep13]

@mkevenaar said...
I think --version and --params are the ones I use mostly. -ia is one that could be added by default as well. Rest could be collapsed like @mwallner suggested.

Okay, cool. I will have a play, and let you know how I get on.

[gep13]

After some (and by that I mean, a lot) of help from @punker76, here is a first draft of all the options...

@AdmiringWorm @mwallner @mkevenaar @ferventcoder what are your thoughts? Anything that should get moved around, changed?

I am thinking that we can make the ChecksumTypes into dropdownlists, that only have the supported checksum types in Chocolatey.

[mwallner]

love it!
imo a slight improvement MAY be to vertically expand if necessary, so that no scrollbar will be shown when expanding the options.
also, bonus points if always only one options drop-down can be expanded at the same time.

this is looking GREAT!

[mkevenaar]

I only got :shipit:

Perhaps "Advanced options" could be different as we are currently in "Install advanced" mode... It seems a bit to much "advanced".

[AdmiringWorm]

Perhaps "Advanced options" could be different as we are currently in "Install advanced" mode... It seems a bit to much "advanced".

"Additional Options" would perhaps be better?
But that could probably cover too much.

In all, everything looks great to me. Although I feel there perhaps is a little too much space after the toggle switches, but that may just be me.

[paul-michalik]

Looks good! Please make sure that the settings persist! Also in that case, we will need some sort of "reset" option and an indication whether advanced settings were used for a package.

[gep13]

@mwallner said...
also, bonus points if always only one options drop-down can be expanded at the same time.

That would be a question for @punker76 😄

[gep13]

@mkevenaar said...
Perhaps "Advanced options" could be different as we are currently in "Install advanced" mode... It seems a bit to much "advanced"

I had the same thought. All strings need to be moved into the Resources.resx file, and at that point, I was going to review all of them.

[gep13]

@paul-michalik said...
Please make sure that the settings persist!

Can you elaborate on what you mean here? I hadn't envisioned persisting any settings.

[steviecoaster]

@paul-michalik said...
Please make sure that the settings persist!

Can you elaborate on what you mean here? I hadn't envisioned persisting any settings.

I'm wondering if this is in reference to enabling useRememberedArguments?

Such that the next time I go to upgrade a package I installed with additional parameters, when I upgrade via the GUI I would like to see the remembered arguments?

Or I'm missing something in the meaning here.

[gep13]

@AdmiringWorm what are your thoughts on the following...

Put two toggle buttons per line.

[gep13]

@steviecoaster I was wondering the same, as this was the only thing that occurred to me as well.

[gep13]

@punker76 you had the idea of loading the available package versions within the Advanced Dialog, using a small loading icon to show that things were working. Is this something that you might be able to provide via a PR into here? Currently this work in done outside of the Dialog, and the available package versions are passed into the Dialog.

[AdmiringWorm]

@gep13 said...
@AdmiringWorm what are your thoughts on the following...

Picture

Put two toggle buttons per line.

Yeah, IMO that looks much better. Still not a fan of the whitespace between the label and the switches (and text boxes) though, mostly because it looks like wasted space. But that isn't really a problem.

[punker76]

@punker76 you had the idea of loading the available package versions within the Advanced Dialog, using a small loading icon to show that things were working. Is this something that you might be able to provide via a PR into here? Currently this work in done outside of the Dialog, and the available package versions are passed into the Dialog.

@gep13 Yes will do this

[ferventcoder]

Just remember loading all available versions causes strain.

[paul-michalik]

@paul-michalik said...
Please make sure that the settings persist!

Can you elaborate on what you mean here? I hadn't envisioned persisting any settings.

I'm wondering if this is in reference to enabling useRememberedArguments?

Such that the next time I go to upgrade a package I installed with additional parameters, when I upgrade via the GUI I would like to see the remembered arguments?

Or I'm missing something in the meaning here.

Exactly. Without such functionality the entire feature isn't going to be very useful - just think about the next upgrade of a package installed with package parameters, for example. This is the issue I keep bumping into for packages with badly chosen defaults such as git.install or cmake.install.

[gep13]

@paul-michalik said...
Exactly. Without such functionality the entire feature isn't going to be very useful - just think about the next upgrade of a package installed with package parameters, for example. This is the issue I keep bumping into for packages with badly chosen defaults such as git.install or cmake.install.

While I like the idea of hydrating the installation options during an upgrade in the UI, I would see that as a separate issue to what is being discussed here. Assuming that you have the useRememberedArguments feature enabled, once you go through the advanced installation window that we are suggesting here, any future upgrades will already use those options.

[punker76]

Here is an update to the UI which was suggested by people here.

• "accordion" like Expander
• Right aligned Labels

So what are you think?

[AdmiringWorm]

@punker76 that honestly looks awesome.

[punker76]

Next update... loading Packages inside dialog with the possibility to cancel this.

...waiting

...cancel it

[gep13]

@punker76 this is really starting to look very good!

[joshieecs]

Just from a user's perspective, it would be convenient if the Package Parameters section in the description wasn't obscured. The modal dialog looks great, but it's going to be frustrating trying to set your scrollbar set just right to see the parameters. It also prevents easily copy-and-pasting if you need several.