GeezerVison is showing github.com — Test-ModuleManifest fails if RequiredModules in module manifest contains entry 'Az' · Issue #8703 · PowerShell/PowerShell
Test-ModuleManifest fails if RequiredModules in module manifest contains entry 'Az' #8703Description
Steps to reproduce
Test-ModuleManifest xxx.psd1 Expected behavior
Actual behavior
Test-ModuleManifest : The specified RequiredModules entry 'Az' in the module manifest 'xxx.psd1' is invalid. Try again after updating this entry with valid values.
At line:1 char:1
+ Test-ModuleManifest xxx.psd1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (xxx.psd1:String) [Test-ModuleManifest], DirectoryNotFoundException
+ FullyQualifiedErrorId : Modules_InvalidRequiredModulesinModuleManifest,Microsoft.PowerShell.Commands.TestModuleManifestCommand
Environment data
Name Value
---- -----
PSVersion 6.1.2
PSEdition Core
GitCommitId 6.1.2
OS Linux 4.15.0-1036-azure #38~16.04.1-Ubuntu SMP Fri Dec 7 03:21:52 UTC 2018
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Emergency
This is effectively blocks a module that depends on Az - the Azure PowerShell module, because when Publish-Module the new module, Test-ModuleManifest is triggered and the failure blocks the publish, we're developing a new module on Az and plan to deliver it to customer in one week, but are stuck at this! Activitycoin8086 commented on Jan 21, 2019 vexx32 commented on Jan 21, 2019 Robert Zhang (@coin8086) for some context, the reason this happens is (to my knowledge) because Az is a reserved culture code, referring to Cyrillic/Azerbaijan.
I believe the PowerShell team ended up having to add an explicit exception in the code so that the Az module would even be properly discovered for autoloading, if I recall the PR correctly.
I agree with you; this is really something that shouldn't have happened in the first place; there's no reason the module name nor the module folder name needed to collide with a reserved culture code, and it should be fixed.
That said, given the outcome of the recent PR here on that matter, PowerShell may end up having to bend on that one as well, however inadvisable it might be.
/cc Steve Lee (@SteveL-MSFT) as I think he was involved in the PR when that issue arose and may want to chime in here. coin8086 commented on Jan 21, 2019 Rain Sallow (/u/ta11ow) (@vexx32) Thanks for your quick reply and input! I'm blocking on this and I believe this also blocks everyone who wants to deliver a module depending on Az. It would be great if PS Core could provide any help. Do you think it helps to keep the issue open on PS Core? Thanks anyway. Michael Yanni (@MiYanni) vexx32 commented on Jan 21, 2019 I'm not sure how complex this particular problem would be to fix frem this side, but I'm sure Steve or one of the others would have a better idea there.
It'd be pretty trivial for the Azure module to just change the name and avoid the problem altogether, but I don't really know if that would cause a wider detrimental impact. coin8086 commented on Jan 21, 2019
I'm not sure how complex this particular problem would be to fix frem this side, but I'm sure Steve or one of the others would have a better idea there.
It'd be pretty trivial for the Azure module to just change the name and avoid the problem altogether, but I don't really know if that would cause a wider detrimental impact.
OK, thanks. I see it. I'm afraid renaming is not their choice, at least in the short time, since that has a lot impact on current document and client code, almost everywhere in Azure.
My last resort would be install Az manually and don't list it in dependency, however troublesome it is. Let's see if there's any better way. coin8086 commented on Jan 21, 2019 changed the title [-]Test-ModuleManifest always fails if the module manifest's RequiredModules contains entry 'Az'[/-] [+]Test-ModuleManifest fails if RequiredModules in module manifest contains entry 'Az'[/+] on Jan 21, 2019SteveL-MSFT commented on Jan 22, 2019 coin8086 commented on Jan 23, 2019
Yes, this is a dupe.
Dup to #8125? Could I know the progress of it? When will you fix it, or do you have an estimated time? Thanks! SteveL-MSFT commented on Jan 29, 2019 nexocentric commented on Mar 29, 2022 I'm currently dealing with issues on related to this bug. Regardless of where it is fixed, what would be a viable work around for someone running into this issue.
I've searched quite a bit on the web and the threads related to this are right on the nose in terms of problems, but there are no solutions.
In my psd1 file, if I specify RequiredModules = @('Az') I run into the issue.
I do not want to specify each Az individual model as I am building against all of it and the expectation is that someone will have this installed locally.
What options do I have to specify the required modules? Is there a wild card that I can specify that will separate it from the Cyrillic/Azerbaijan locale that it is hitting?
Maybe even a alias for the Az modules that allows me to specify all of the Az modules.
Thanks for your help and support.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|