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

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

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.

module names should be case insensitive.

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

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.

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.

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?

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.

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.

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

4ndri (@4ndri)

📣 Hey 4ndri (@4ndri), how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

RE: "working as intended. issue with PSResourceGet".

I agree with this, as the last time I've checked, like a year ago, it was PSResourceGet that was installing modules on linux into incorrectly cased directories (PowerShell/PSResourceGet#1402, PowerShell/PSResourceGet#1446).

Navigation Menu

Repository navigation

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

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Activity

4ndri commented on May 14, 2022

237dmitry commented on May 14, 2022

4ndri commented on May 14, 2022

FH-Inway commented on Jul 8, 2023

rickandersen-forte commented on Oct 15, 2023

4ndri commented on Oct 16, 2023

JamesWTruher commented on Oct 28, 2024

microsoft-github-policy-service commented on Oct 30, 2024

microsoft-github-policy-service commented on Oct 30, 2024

jtomkiew-mng commented on Oct 30, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions