You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GetPersonalModulePath() should be made a public method, and be configurable from powershell.config.json #18613
"As a user, I want to specify where my modules are installed by default, such as a non-OneDrive path or another drive for performance"
While a powershell.config.json setting exists to allow configuration of the PSModulePath, it does not allow someone to set the default install location for modules. The logic for this is hidden in an internal method, and as a result, products like PowerShellGet v2, PowershellGetv3, and ModuleFast have their own separate internal implementations that mirror this method.
By making the method public, and making the target overridable in powershell.config.json, package management tools can tie into PowerShell to be consistent with the intent of the use.
I believe James Truher (@JamesWTruher) was going to tackle this as a pre-requisite to #15552. Specifically exposing an API to retrieve the user, shared, and system module paths. This would be needed by PowerShellGet rather than using a priori knowledge. I believe Jim had some concerns with simply making those APIs public instead of some sanitized versions, but don't recall the details.
Kirill Osenkov (@KirillOsenkov) for note I am not a maintainer of the PowerShell repo, I'm just a community member, there's nothing I can do in this regard.
Note that I've marked it as declined here but it could probably more easily be labeled as duplicate. The feature itself is still planned and tracked separately, the specific implementation suggestion is declined. Hopefully that makes sense
Activity
SteveL-MSFT commentedon Nov 21, 2022
I believe James Truher (@JamesWTruher) was going to tackle this as a pre-requisite to #15552. Specifically exposing an API to retrieve the user, shared, and system module paths. This would be needed by PowerShellGet rather than using a priori knowledge. I believe Jim had some concerns with simply making those APIs public instead of some sanitized versions, but don't recall the details.
KirillOsenkov commentedon Apr 4, 2024
Can we please reactivate
KirillOsenkov commentedon Apr 4, 2024
Justin Grote (@JustinGrote) Steve Lee (@SteveL-MSFT)
JustinGrote commentedon Apr 4, 2024
Kirill Osenkov (@KirillOsenkov) for note I am not a maintainer of the PowerShell repo, I'm just a community member, there's nothing I can do in this regard.
KirillOsenkov commentedon Apr 4, 2024
sorry I thought you could reactivate as the author
MatejKafka commentedon Apr 5, 2024
Ryan Yates (@kilasuit) not completed, please reopen
6 remaining items
SeeminglyScience commentedon Sep 16, 2024
Note that I've marked it as declined here but it could probably more easily be labeled as duplicate. The feature itself is still planned and tracked separately, the specific implementation suggestion is declined. Hopefully that makes sense
JustinGrote commentedon Sep 16, 2024
Yep makes sense, closing here.
microsoft-github-policy-service commentedon Sep 16, 2024
📣 Hey Justin Grote (@JustinGrote), how did we do? We would love to hear your feedback with the link below! 🗣️
🔗 https://aka.ms/PSRepoFeedback
microsoft-github-policy-service commentedon Sep 16, 2024
📣 Hey Justin Grote (@JustinGrote), how did we do? We would love to hear your feedback with the link below! 🗣️
🔗 https://aka.ms/PSRepoFeedback