search

aws / aws-tools-for-powershell

The AWS Tools for PowerShell lets developers and administrators manage their AWS services from the PowerShell scripting environment.
Apache License 2.0
238 stars 79 forks source link

Add wildcard glob to Install-AWSToolsModule -Name property #73

Closed tlindsay42 closed 3 years ago

tlindsay42 commented 4 years ago

Expected Behavior

The Name parameter of the Install-AWSToolsModule cmdlet should allow a wildcard for users that want to install all AWS service modules.

Current Behavior

The Name parameter of the Install-AWSToolsModule cmdlet does not feature a wildcard glob as a valid value for installing all AWS service modules if so desired. Also, the resulting error from attempting to do so is not very helpful.

PS C:\> Install-AWSToolsModule -Name '*'
ForEach-Object : A positional parameter cannot be found that accepts argument 'System.Collections.Hashtable'.
At ~\Documents\WindowsPowerShell\Modules\AWS.Tools.Installer\1.0.0.0\AWS.Tools.Installer.psm1:250
char:37
+ ... s = $Name | ForEach-Object { Find-Module -Name $_ $findModuleParams @ ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [ForEach-Object], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.ForEachObjectCommand

Possible Solution

Add '*' as a valid value for the Name parameter of the Install-AWSToolsModule cmdlet and add [SupportsWildcards()] so that the documentation reflects when reviewing the Accept wildcard characters? attribute of the Name property of the Install-AWSToolsModule cmdlet.

PS C:\> Get-Help -Name Install-AWSToolsModule -Full

NAME
    Install-AWSToolsModule

SYNOPSIS
    Install AWS.Tools modules.

SYNTAX
    Install-AWSToolsModule [-Name] <String[]> [[-RequiredVersion] <Version>] [-MaximumVersion <Version>] [-CleanUp]
    [-SkipUpdate] [-Scope <String>] [-AllowClobber] [-Proxy <Uri>] [-ProxyCredential <PSCredential>] [-Force]
    [-WhatIf] [-Confirm] [<CommonParameters>]

DESCRIPTION
    This cmdlet uses Instal-Module to install AWS.Tools modules.
    Unless -SkipUpdate is specified, this cmdlet also updates all other currently installed AWS.Tools modules to the
    version being installed.

PARAMETERS
    -Name <String[]>
        Specifies names of the AWS.Tools modules to install.
        The names can be listed either with or without the "AWS.Tools." prefix (i.e. "AWS.Tools.Common" or simply
        "Common").

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?       true (ByValue, ByPropertyName)
        Accept wildcard characters?  false

Context

End users do not have an easy way to install all AWS service modules if so desired. Discussed an issue with the likely alternative privately with @matteo-prosperi.

Your Environment

Include as many relevant details about the environment where the bug was discovered.

(Get-Module -Name 'AWS.Tools.Installer').Version

Major  Minor  Build  Revision
-----  -----  -----  --------
1      0      0      0
matteo-prosperi commented 4 years ago

We have considered allowing a way to install all AWS.Tools modules in a single operations (either by allowing Install-AWSToolsModule * or by creating an empty module which references all others as dependencies (so that Install-Module would install all of them). Unfortunately Install-Module takes too long to install the 180 AWS.Tools modules. It takes a very long time to import 180 modules as well. Creating an easy way to install all modules would imply that we endorse it as a good practice and would drive users into a very bad experience. We think it is best to push users towards installing only the modules they need.

tlindsay42 commented 4 years ago

I agree with your points, but still think we could create a better customer experience by providing the functionality and communicating guidance at the confirmation prompt and in the documentation to encourage best practices.

Optimally, we want customers to be learning & experimenting with the full suite of AWS services, so we should make it easier to do so. Scaling back from the full set, if a DevOps team is scripting against 179 AWS services deployed in production, is it a better experience to have to install the 179 modules individually than install all 180? What about 150? 100? 50? 30? The break-even point will be a matter of personal taste, and it could change for some as the AWS service catalog continues to grow.

Also, there will always be scripters that want ease-of-use over performance, and there are easy alternatives to accomplish this that won't have safeguards built into it, so encouraging use of the proposed functionality when required enhances consumer safety.

FireInWinter commented 4 years ago

I totally don't agree that forcing people into doing research before they can install the tools is a good idea. You install what you need when you understand what you need. Before then you will probably be frustrated by the installer. This also breaks expectations from that come from the monolithic version. You would install the 1 module and get access to all modules. Now you have to jump hoops to get a list of all the modules you could install. There isn't even a Get-AWSToolsModule function.

Maybe if you added a Get-AWSToolsModule people who want all modules, current and future, can do a Install-AWSToolsModule -Name (Get-AWSToolsModule).Name to get all the modules installed. You can do a Find-Module AWS.Tools.*, but that returns 207 items, not all of which you want to install after you have the installer installed. And installing all of those isn't really secure anyway as someone could create a new module that does something bad i.e "AWS.Tools.MalWare".

Using the 3.3.x version a while ago I was able to find new functionality almost immediately. I was looking for Get-ORGAccountList, but didn't know what it was called. I also hadn't done anything with the ORG prefix before. I was able to do a gcm -Module awspowershell get-*account* to see EVERYTHING that had to do with accounts. I could then look through the list and easily find the command I wanted. Now I have to spend extra time online to figure out which module it is located in, in order to then install it, to finally figure out if it was the one I wanted. If it isn't, then I have to start the process over again. Also, telling people they need to figure out which 30 modules of 180+ they need to install seems like a really bad customer experience. I don't think I would ever bother with figuring out exactly which ones to install unless I only needed 1 or 2.

So please add a option to the Install, it makes it easier to use and easier to discover functions. This wouldn't be an issue, but it looks like the individual AWS.Tools. modules will eventually replace both of the monolithic versions.

andyhopp commented 4 years ago

Hello! @FireInWinter, if you really do want to install all modules, we have a Cmdlet named Get-AWSService that can list all known services. One of the properties of the return list of objects is ModuleName, so if you like, you can run a command like: Install-AWSToolsModule (Get-AWSService).ModuleName

I just tested this on my box, and it does take quite a while to install them all (10 minutes). If you do follow the above, you do not need to import all of the modules; simply importing AWSTools.Common will enable you to use the Cmdlets for all of the installed services. Import-Module AWS.Tools.Common

austoonz commented 4 years ago

While it will break future use of the *-Module cmdlets without using “-Force”, the team also release the three AWS Tools for PowerShell variants in zip format.

This is detailed in the documentation under “Downloading the modules from AWS.Tools.zip and extracting them in one of the module folders.”

This is definitely the fastest way for installing all the AWS.Tools modules.

ashishdhingra commented 3 years ago

Closing this issue since it is labeled wont-fix. Please reopen if anyone thinks otherwise.