Install module to 'Program Files' and remove modifying $PROFILE #578
Conversation
|
I'll take a closer look at your new code later, but for now:
|
| catch {} | ||
| throw | ||
| if ($PSVersionTable.PSVersion.Major -lt 4) { | ||
| $modulePaths = [Environment]::GetEnvironmentVariable('PSModulePath', 'Machine') -split ';' |
There was a problem hiding this comment.
Can we assume no one will try to use Chocolatey to install this on Linux or macOS? If not, you should use [System.IO.Path]::PathSeparator instead of hard-coding in ;.
There was a problem hiding this comment.
For the time being we can. As per the next comment this is only for v0 so we don't need to worry about PS Core.
| Remove-Module -Name $moduleName -Force -ErrorAction SilentlyContinue | ||
|
|
||
| $sourcePath = Join-Path -Path $toolsDir -ChildPath "$modulename\*" | ||
| $destPath = Join-Path -Path $env:ProgramFiles -ChildPath "WindowsPowerShell\Modules\$moduleName" |
There was a problem hiding this comment.
A big part of the v1 release is to support PowerShell Core. If the user has PS Core installed, we should also install into "PowerShell\Modules\$moduleName" if the $env:ProgramFiles\PowerShell dir exists.
There was a problem hiding this comment.
I agree. I have been wondering what to do about whether you run Chocolatey under Core or not and where you should put the modules. However this is purely for the v0 branch so PS Core wasn't a consideration.
|
RE:
Don't mean to sound like a broken record but ... with a build script - or at least a publish script - we could copy the relevant module files for distribution into an out dir. Which I have proposed would be |
I think the way you should do this is to allow the user to opt in to modifying the profile. Let me try and explain. If you have an op-out then when I install it I use If you have opt-in then when I install it I use The difference is an opt-out will try and modify my profile every single time the package is installed / upgraded and I need to try and stop it. An opt-in only modifies the profile at install (with the parameter) and not every time I install / upgrade. But it only has to modify the profile once anyway. If a user doesn't opt-in but wishes they had they can always reinstall the package or simply use the |
|
Can our Chocolatey installer tell if it's a clean install or an upgrade? Assuming we're installing into a location in Ultimately for |
You can simply detect if the module exists as a loadable module or not. But you'll need to add some extra code around checking the tools folder. |
This is the Chocolatey package install / uninstall files I use which copies the embedded module to the
Program Files\WindowsPowerShell\Modulesfolder.The module itself is embedded into the package for easier distribution and I do this using an automatic update script. As you're not using that then simply add the code you want to distribute into a folder called
posh-gitwithin the tools folder. Inside theposh-gitfolder should be the code itself. The installer script takes care of creating a version folder if needed for PS 5+.See my other modules for PSScriptAnalyzer, PSCodeHealth, Plaster, PlatyPS, PSStringTemplate and EditorServicesCommandSuite here for more info.