Repository navigation
Import-Module not working if psd1 and module folder has different casing (on unix) #17342
Description
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 testmoduleExpected 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 : -2147024894Environment 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.0Visuals
No response
Activity
4ndri commentedon May 14, 2022
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 commentedon May 14, 2022
This is not Windows. Script names are also case sensitive.
4ndri commentedon May 14, 2022
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-ModuleI expect that all these possibilities should work.
FH-Inway commentedon Jul 8, 2023
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 commentedon Oct 15, 2023
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 commentedon Oct 16, 2023
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 commentedon Oct 28, 2024
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 commentedon Oct 30, 2024
This issue has been marked as by-design and has not had any activity for 1 day. It has been closed for housekeeping purposes.
microsoft-github-policy-service commentedon Oct 30, 2024
📣 Hey 4ndri (@4ndri), how did we do? We would love to hear your feedback with the link below! 🗣️
🔗 https://aka.ms/PSRepoFeedback
jtomkiew-mng commentedon Oct 30, 2024
RE: "working as intended. issue with
PSResourceGet".I agree with this, as the last time I've checked, like a year ago, it was
PSResourceGetthat was installing modules on linux into incorrectly cased directories (PowerShell/PSResourceGet#1402, PowerShell/PSResourceGet#1446).