Now we're getting to the meaty part, the
part you've no doubt been waiting for.
Let's go and find and install some modules
from the PowerShell Gallery. Another key
command in the PowerShellGet module is
named Find‑Module, and I'm sure you'll be
shocked to hear that this is the command
we use to find modules in a repository.
Let's take a look at the help for
Find‑Module. Interestingly, there are no
required parameters here, but there are
some interesting parameters here, such as
MinimumVersion, MaximumVersion, and the
RequiredVersion. There's also one that I
want to point out to you here that we
don't actually work within this course,
but I do want you to be aware of it, which
is IncludeDependencies. Sometimes you'll
come across a PowerShell module which
depends on another PowerShell module for
it to function fully. You can use the
IncludeDependencies parameter to get shown
if modules have dependencies, and if they
do, what they are. Similarly, when it
comes time to install modules, if you
install one that has a dependency on
another module, it will often install that
dependency for you in the background.
Let's run Find‑Module with no parameters,
as the help told me this should work. And
yep, here we go. This will go and find
every single module that exists in the
repositories I've currently got
registered. As much as I like fun
activities like watching paint dry, I'm
going to press Ctrl+C to stop that so we
can try out a few other things. We can run
Find‑Module and use the Name parameter to
start filtering our search. Now, I'm
assuming you probably know about Slack,
the popular communication tool. If you
don't, that's all good, as we're not going
to use Slack itself, but someone the other
day was telling me about a PowerShell
module that exists for Slack but I can't
remember the name of it. So let me put
Slack in for the name, but with asterisk
to perform a wildcard search. Okay, cool,
we've got a number of results there, and
it happens to be the first result,
PSSlack, that I was thinking about. You
can also search based on tags. So you can
run Find‑Module ‑Tag Slack. As authors
update their modules to fix bugs or add
new capabilities, they publish new
versions of a module. Find‑Module, by
default, unless told otherwise, will
return the latest version of a module at
that point in time from the repository.
There's a parameter named AllVersions that
can be used to display all historical
versions of a particular module. So we
could run Find‑Module ‑Name PSSlack
‑AllVersions, and we'll see this module
has had a number of releases over time,
with 1.0.5 being the newest. We could also
use the MaximumVersion parameter, which
will return the newest version of the
module that does not exceed the version
specified. So if we enter that as 1.0,
even though a newer version than 1.0 does
exist, it won't show us that, as we've
manually capped the maximum version that
Find‑Module should go and get for us.
There's another parameter named
RequiredVersion. If you are looking for a
very specific version of a module, you can
use RequiredVersion to limit your search.
So let's say we were after version 1.0.2.
We can be specific about that and only get
that version returned. The last parameter
of Find‑Module that I want you to be aware
of is named Repository. So by default
Find‑Module will search all of the
repositories you have registered. If you
want to limit the repositories Find‑Module
will use when you have more than one
repository, you can use this Repository
parameter to tell it specifically which
repository to look in. Lastly, before we
get onto installing this PSSlack module,
there's another handy command for
discovery that you might like to use
called Find‑Command. So instead of just
finding the module, you can use
Find‑Command to be a bit more granular
with your searching to discover commands.
If I run Find‑Command ‑ModuleName PSSlack,
we'll see all of the commands that are
available inside of that module, so before
even installing it, I can take a look at
what sort of functionality is included in
this module to see if it might be the kind
of thing that I'm actually looking for.
And finally, if you know the name of a
specific command, maybe you saw it online
or someone told you about it, or you've
used it before but you can't quite
remember which module it's a part of, you
can use Find‑Command to search for a
specific command. Let me look for the
command named Get‑VM, and we'll see that
Get‑VM is a command in two modules on the
PowerShell Gallery. Come on, Matt, I hear
you say, we've inspected the module
enough, let's get it installed. Alright,
alright. To do that, we need to use the
command named Install‑Module. Let's check
out the help with get‑help Install‑Module.
For this one, the only required parameter
is the name of the module, and we do have
options there to specify the particular
version by using similar parameters that
we just looked at on the Find‑Module
command. There's a parameter here named
AllowClobber, and while we won't be using
this, it's good to know about. Similar to
AllowClobber on Import‑Module that we
looked at in the last module of this
course, using AllowClobber on
Install‑Module lets you confirm that you
want to install a module that has
conflicting commands with a module that is
already installed on your machine. There's
also a particular parameter I do want to
point out named Scope. And listen up, this
is really important. I'm going to bring up
our PSModulePaths in the console here to
help explain this as well. The Scope
parameter accepts two values, AllUsers and
CurrentUser. If you specify AllUsers, the
module will get installed in a location
that is accessible by all users on this
computer, such as this location here in
the Program Files folder. If you specify
CurrentUser for the Scope, the module gets
installed in a location that is only
accessible to the current user of the
computer, such as this folder here, which
is inside of my user profile, so if
someone else logs onto this machine, they
wouldn't have access to that module that
I've installed. Now Scope is optional, so
there's some default behavior, and the
default behavior differs based on which
version of PowerShellGet you have. With
PowerShellGet version 1, the default scope
is AllUsers, which requires elevation of
the PowerShell session for installation of
a module. With PowerShellGet version 2 and
above, the default scope is CurrentUser,
which does not require elevation for
install. The version of PowerShellGet can
be checked with a Get‑Module
PowerShellGet, and interestingly enough, I
actually have version 1 and version 2.
Version 1 was installed by default with
Windows 10, but version 2 of PowerShellGet
was installed when I installed PowerShell
7. By default, when this happens,
PowerShell will load the newest version.
So we're currently running version 2 of
PowerShellGet, so by default this module
is going to be installed in the
CurrentUser scope. Let's give installing a
module a go. I'll run Install‑Module
PSSlack. The ‑Name parameter was optional,
as this is a positional parameter, and
this will go and look for a module named
PSSlack in our registered repositories,
and it found the one in the PowerShell
Gallery. And, as expected, it's telling me
that I'm about to install a module from an
untrusted repository, and am I sure I
actually want to do this. I'm pretty sure,
so I'll say y to that. And that's it, the
PSSlack module is now installed on my
machine. Pretty simple, right? I'll run
Get‑Module PSSlack using the
‑ListAvailable parameter because it's not
yet imported into this session, and I'm
going to pipe that to format list. What I
want to highlight here is that the module
got installed into the PSModulePath under
my user profile because that's the default
with PowerShellGet version 2. You'll
definitely want to be aware of this Scope
behavior as you start working with
modules. Finishing up here, now that the
PSSlack module is installed, we can run
Get‑Command, specifying the PSSlack module
to see which commands we can now start
using, having now installed this module.
And one last thing I want you to be aware
of is even though I won't actually show it
in any of these demos, a lot of these
commands in the PowerShellGet module can
be piped to one another. So, for example,
you could do a Find‑Module to figure out
what you're looking for, and then just
pipe that directly to Install‑Module
rather than explicitly running
Install‑Module and specifying the module
name. I'm being very particular to run
each command separately to ensure you're
clear on what's happening in each step,
but I did want to mention that if you're
comfortable with piping, please feel free to do so.