Allow for passing in package parameters / installer arguments when installing a package

ferventcoder commented 6 years ago

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~ (Not needed)
[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
[ ] Versions should be sorted from newest to oldest
[x] 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
[ ] There should be a checkbox to control whether pre-release package versions are included in the combobox
[ ] 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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 4 years ago

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 commented 4 years ago

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

gep13 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

mkevenaar commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

for_issue

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

Put two toggle buttons per line.

gep13 commented 4 years ago

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

gep13 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

Just remember loading all available versions causes strain.

paul-michalik commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

"accordion" like Expander
Right aligned Labels

So what are you think?

chocogui_advanced_install2

AdmiringWorm commented 4 years ago

@punker76 that honestly looks awesome.

punker76 commented 4 years ago

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

...waiting

chocogui_advanced_install3

...cancel it

chocogui_advanced_install4

gep13 commented 4 years ago

@punker76 this is really starting to look very good!

joshieecs commented 4 years ago

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.

gep13 commented 3 years ago

Re-opening this until I verify that all of the items in the original issue description have been completed.

gep13 commented 2 years ago

@AdmiringWorm can you update the checkboxes in the description of this issue? If any of them haven't been completed, or are in-complete, can you create follow up issues to track that functionality getting added? Thanks

AdmiringWorm commented 2 years ago

@gep13 the checkboxes have been updated with what is currently included, with a followup issue #913 created

steviecoaster commented 2 years ago

@gep13 @AdmiringWorm just to ensure I have correct information, is SXS (side by side) installation support in this release then? I see notes that it was discussed but haven't gone through all the commits to try and find it, as I figured asking here might be faster than my hunting :)

AdmiringWorm commented 2 years ago

@steviecoaster SXS is added to the advanced installation.

Unless I have missed some, all arguments supported by open-source Chocolatey are supported except for specifying the custom log file path.

gep13 commented 2 years ago

:tada: This issue has been resolved in version 0.20.0 :tada:

The release is available on:

Your GitReleaseManager bot :package::rocket:

chocolatey / ChocolateyGUI