Import-Module not working if psd1 and module folder has different casing (on unix)

[4ndri]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

• open powershell on linux
• import a module, where casing of the psd1 file is different to the casing of the module folder.
  run the following script for repro:

$modulesPath= "$(Get-Location)/modules/";
$env:PSModulePath += [System.IO.Path]::PathSeparator + $modulesPath
$moduleName = "testmodule";
New-Item -ItemType Directory -Path "$modulesPath/$moduleName" -Force > $null
New-ModuleManifest -Path "$modulesPath/$moduleName/$($moduleName.ToUpper()).psd1" -RootModule "TestModule.psm1" -ModuleVersion 1.1
Set-Content -Path "$modulesPath/$moduleName/TestModule.psm1" -Value "function mytest{'hello' }"
Import-Module testmodule

Expected behavior

module names should be case insensitive. the module should load.

Actual behavior

Error: The specified module 'testmodule' was not loaded because no valid module file was found in any module directory.

Error details

Exception : 
 Type : System.IO.FileNotFoundException
 Message : The specified module 'testmodule' was not loaded because no valid module file was found in any module directory.
 HResult : -2147024894

Environment data

Name Value
---- -----
PSVersion 7.2.3
PSEdition Core
GitCommitId 7.2.3
OS Linux 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022
Platform Unix
PSCompatibleVersions{1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Visuals

No response

[4ndri]

this issue is similar to #1621 which was resolved in PR #5097. but the assumption was made, that psd1/psm1 file always has the same casing as the folder name. I think that's wrong, because there are other methods to install modules than with PSGet.

i.e. if dependencies are installed with dotnet/nuget. nuget forces lowercase for package folder (NuGet/Home#3840). this results in different casing for the module folder name and the psd1 file.

[237dmitry]

module names should be case insensitive.

This is not Windows. Script names are also case sensitive.

[4ndri]

module names are already case-insensitive (even on Unix). the discussion about case-sensitivity of modules was resolved here: #706 (comment)

the following table shows the current behavior of Import-Module

ModuleFolder	psd1-File	Import-Module ByName	Result
testmodule	testmodule.psd1	testmodule	works
testmodule	testmodule.psd1	TESTmodule	works
testmodule	TestModule.psd1	testmodule	error
testmodule	TestModule.psd1	TestModule	error

I expect that all these possibilities should work.

[FH-Inway]

I just ran into this issue as well and spent a couple of hours trying to figure out what is going on. At the very least the error message should be improved.

[rickandersen-forte]

Doesn't this cause all nuget packages to fail? Or at least, all nuget packages that include an uppercase letter? If I understand correctly (and I'm not sure I do), it has been decided in nuget #3840 that all nuget packages will be forced to lowercase. As a result, all PS modules that include a capital letter installed via a nuget package would get an invalid directory name and thus would fail on any case-sensitive file system. I'm sure that's not happening, so what am I missing? Is there something I need to do to get Publish-PSResource to generate a mixed-case nupkg file?

[4ndri]

if the module is installed with PSGet, everything works. PSGet installs the module with correct casing.

but if the module is installed with nuget, upper cased modules can't be imported on unix filesystem. in #5097 (comment) they assumed that casing of folder and psd1 or psm1 is always the same. nuget breaks this assumption with its lowercasing.

[JamesWTruher]

The WG discussed this, and while at first blush it may appear this is easily addressed, there are some very subtle issues that may arise. Most problematic is that if there are multiple psd1 files, and they all have inconsistencies with regard to case against reality, where none are correct, what should be behavior be? In this case, just describing that would be quite voluminous. Because the module name refers to something on the filesystem, the WG believes that we should be case sensitive in those situations, and believe that we are working as designed at present.

We suggest that tooling should be improved (such as PSResourceGet) to catch these issues in the authoring and publishing process.

[microsoft-github-policy-service]

This issue has been marked as by-design and has not had any activity for 1 day. It has been closed for housekeeping purposes.