Do not post any licensing information in this forum.
another feature request has come up:
I'd like to be able to specify additional paths for where PowerShell Studio looks for modules. For each path I'd assign a numerical weight, in case the same module is available in multiple paths (including the default ones). This way I can choose which Module Version to provide Primal Sense for.
The default Module paths ($env:PSModulePath) are automatically added with default weight 0.
a) | C:\Users\UserName\Documents\WindowsPowerShell\Modules | Weight 1 (Added by default, manually changed weight)
b) | C:\Program Files\WindowsPowerShell\Modules | Weight 0 (Added by default)
c) | C:\Windows\system32\WindowsPowerShell\v1.0\Modules | Weight 0 (Added by default)
d) | \\srv-dev\Modules | Weight 2 (Added manually)
e) | \\srv-dev\Modules_Alpha | Weight 3 (Added manually)
ModuleA (Found in Paths: a), d), e) )
ModuleB (Found in Paths: a), b), d) )
Received Primal Sense from
ModuleA --> Path e)
ModuleB --> Path d)
We have a project involving multiple developers, source code control softwares and development computers. It consists of multiple PowerShell Modules (currently 5, but according to the design plan it will end up with 12). It is not practical to mirror them into default folders for each dev, as some modules in alpha stages will break the help system of powershell if present in a folder where powershell can find it. Furthermore, it simply adds a complexity that is not desired.
Being able to manually configure the folders used for Primal Sense for PSS only would solve this issue handily, and a priority system (like the weight numbers described in the example) allows controlling what Version of the same module Primal Sense is provided for (So I can have the last stable build for use in the console and receive Primal Sense for the Alpha of the latest version).
Expected usefulness in general
- Allows better coexistence between development builds and production deployments of modules.
- Simpler collaboration during multi-module development
Note: With PowerShell v5 you can specify which version of the module you wish to load using the FullyQualifiedName parameter (Assuming they have different version numbers).
Thank you for your feedback.
SAPIEN Technologies, Inc.
nice to see it on the wishlist - especially considering we're approaching the time of year where wishes sometimes come true ^^
Aye, however in my current use-case that's a no-go - v4 is all we can use. Unfortunately I wouldn't want to rely on all devs maintaining correct Versioning for anything but production builds.davidc wrote:Note: With PowerShell v5 you can specify which version of the module you wish to load using the FullyQualifiedName parameter (Assuming they have different version numbers).
Who is online
Users browsing this forum: No registered users and 7 guests