GeezerVison

The static analysis failure is not related to this PR. I'll submit a fix for it in a separate PR.

The PR description is updated as we are not using recursion when searching for modules.

Could someone help me understand the delivery vehicle and timing for this fix? Is this a fix for Windows PowerShell 5.1 or for PowerShell Core (6.0)? If Windows PowerShell 5.1, would that mean delivery would be part of a 5.2 type release? Are consumers today completely blocked from building module dependencies on the new Az module until this is resolved?

Ron Howe (@ronhowe) The fix is only for PowerShell Core. You'll get it in PowerShell Core 6.2 RC in hours and in release PowerShell Core 6.2 in weeks.

Windows PowerShell 5.2 is not expected. Although MSFT may port this fix to 5.1.

Are consumers today completely blocked from building module dependencies on the new Az module until this is resolved?

The problem is only for auto discovering. You could use full path to explicitly load the module.

Ron Howe (@ronhowe): to reiterate what Ilya (@iSazonov) said, our bar for servicing Windows PowerShell is very high now, and we do not plan to do a 5.2 release. This has resulted in a small handful of security and accessibility fixes, and some bug fixes to fix regressions associated with those two.

That being said, I want to talk to the Azure PowerShell team about this (/cc Scott Phibbs (@sphibbs) and Mark Cowlishaw (@markcowl) for context), as I don't want us limiting the adoption of Az in any way.

In the meantime, using Import-Module Az explicitly (even without the full path, I believe), the module will load and you can use it.

Apparently, it may also be the case that RequiredModules will fail because it secretly uses Get-Module -ListAvailable under the hood (which is where we're doing the locale optimization).

But like I said, I'll follow up with the Azure PS to get their sense of the impact.

Pure curiosity and off-topic, but I'd also love to hear what's keeping you from using PowerShell Core. :)

Dove a little deeper on this...Ron Howe (@ronhowe): what exactly is the problem you're experiencing?

We've confirmed that RequiredModules doesn't work with Az, but Az is a phony module that exports nothing, and you shouldn't be pulling every single Az.* module into your RequiredModules, you should be explicitly specifying the Az.* modules that you need.

Additionally, because Az exports nothing and is the only module affected here, autoloading shouldn't actually be impacted for any of the cmdlets in Az.* modules.

So again, how are you actually being affected here?

Dove a little deeper on this...Ron Howe (@ronhowe): what exactly is the problem you're experiencing?

We've confirmed that RequiredModules doesn't work with Az, but Az is a phony module that exports nothing, and you shouldn't be pulling every single Az.* module into your RequiredModules, you should be explicitly specifying the Az.* modules that you need.

Additionally, because Az exports nothing and is the only module affected here, autoloading shouldn't actually be impacted for any of the cmdlets in Az.* modules.

So again, how are you actually being affected here?

I just read this and that's the exact problem. I can try to be more selective about what my module imports.

As to why we aren't using PowerShell Core? I'm all for that. It's a bit more difficult to spearhead that adoption across my company. I am at the frontline of that effort, but it's a much slower ship and we have more immediate needs.

The impact is that the user is given the AZ as an easy way to instal and manage the Azure module with all it's dependent modules. But the user cannot call Get-Module to see what version of the module they have.

With everyone writing their own module install\update logic, we have to walk the $env:psmodulepath just for this module to determine if we should install the module or update it. So we are leaving it on the end user to solve for this.

You'd think that the Azure team would be verifying that the module works as expected in a majority of use cases before finalizing a module structure that is actually broken on both the supposedly supported platforms.

I guess for whatever reason... these cases were overlooked. I don't know that I could fault the PS team for this behaviour moreso than the Azure team for not checking that the module functions as expected with the structure they chose. :/

Both teams are failing ME - the user.
by not fixing in 5.x and by the AZ name not being tested properly.