Closed tlindsay42 closed 3 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.
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.
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.
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
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.
Closing this issue since it is labeled wont-fix
. Please reopen if anyone thinks otherwise.
Expected Behavior
The
Name
parameter of theInstall-AWSToolsModule
cmdlet should allow a wildcard for users that want to install all AWS service modules.Current Behavior
The
Name
parameter of theInstall-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.Possible Solution
Add '*' as a valid value for the
Name
parameter of theInstall-AWSToolsModule
cmdlet and add [SupportsWildcards()] so that the documentation reflects when reviewing theAccept wildcard characters?
attribute of theName
property of theInstall-AWSToolsModule
cmdlet.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-AWSPowerShellVersion
: 1.0.0.0 (NOTE: I haven't installed AWS.Tools.Common yet on my Windows PowerShell 5.1 version yet, soGet-AWSPowerShellVersion
isn't available, so you may want to adjust the suggestion here)$PSVersionTable.OS
: Microsoft Windows 10.0.17763 (NOTE:$PSVersionTable.OS
is not a valid property in Windows PowerShell, so I had to run this from my PowerShell 6.2 instance)$PSVersionTable.PSEdition
: Desktop