[WIP] conda 4.4 powershell wrapper

[kalefranz]

No description provided.

[kalefranz]

#626

[mbargull]

Some code regarding prompt support can be found in the previous PR #6090 by @HyundongHwang.

[mbargull]

Prompt code is also in https://github.com/BCSharp/PSCondaEnvs/blob/052698cf442320ac635eac2391dcb7f0766a49e0/activate.ps1#L129-L133

[kalefranz]

Yeah as soon as I'm able to finally wrap up #6518 I was going to see if @BCSharp was interested in contributing the official powershell wrapper that makes use of the new framework.

My biggest unknown at the moment is the "right" way to initialize powershell and bootstrap in the conda-specific code. E.g. for bash we have option (1) modify ~/.bashrc with something like

. /path/to/conda_base/etc/conda/conda.sh

(or the eval that'll fall out of #6518), or option (2) adding a file /etc/profile.d/conda.sh that does something similar.

[kenodegard]

It would appear that the "proper" way in PowerShell is to add the conda.ps1 into the $profile script. The only issue I see with that is that the user will need to modify their ExecutionPolicy before Powershell will (1) even read their own $profile script and (2) also read the conda.ps1 script.

Given the ExecutionPolices, I think that you would want to get the conda.ps1 script signed (whatever that means and however one would do that).

[zooba]

I would recommend doing it this way:

• rename to conda.psm1 (that makes it a module)
• add Export-ModuleMember -Function conda at the end of the file
• sign the .psm1 with your usual code signing certificate
• install/copy it to either %UserProfile%\Documents\WindowsPowerShell\Modules\Conda or %ProgramFiles%\WindowsPowerShell\Modules\Conda (for both 32 and 64-bit variants, I believe)

PowerShell will scan the files in these directories and automatically import them when the user invokes the exported command, so you shouldn't have to configure anything other than the installation.

Also, for "good" PowerShell style, I'd recommend:

• rename the function to Invoke-Conda
• add New-Alias conda Invoke-Conda -Force and Export-ModuleMember -Alias conda at the end of the module
• define as many parameters as feasible (this page should help) and avoid using $args
• depending on how committed you are here, bringing the commands up a level and having (e.g.) Install-CondaPackage etc. commands that simply turn into Invoke-Conda install ... would make this feel like an impressively native experience for PS users (though it may also make a nice project for "someone else"). Or dynamic parameter sets (see the link above) would also be neat.

[kalefranz]

Thanks @zooba that's exactly what we needed.

[kalefranz]

https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-macos-and-linux?view=powershell-6#paths

• $PSHOME is /opt/microsoft/powershell/6.0.0/
• User modules will be read from ~/.local/share/powershell/Modules
• Shared modules will be read from /usr/local/share/powershell/Modules
• Default modules will be read from $PSHOME/Modules

[kalefranz]

Update on where we are with shell wrappers in current master (4.6.x).

First, all the shell wrapper files have moved slightly. They're now at https://github.com/conda/conda/blob/710d30a9cc2e2417c00c0fcdc188eeff2216fb2f/conda/shell. We currently have five varieties:

• generic posix shell (ash, bash, dash, zsh, busybox, etc) via conda.sh
• the cmd.exe prompt via conda.bat (and lots of other helper bat files)
• tcsh (though I don't think csh works currently) via conda.csh
• fish via conda.fish
• xonsh via conda.xsh

In 4.6, there is a new conda init command specifically to help users set up shell wrappers correctly. The logic and implementation for conda init is in https://github.com/conda/conda/blob/710d30a9cc2e2417c00c0fcdc188eeff2216fb2f/conda/core/initialize.py. The approach we've taken in conda init for setting up shells is borrowed from https://direnv.net/. The bash case, for example, adds a block of code to ~/.bashrc / ~/.bash_profile that is basically eval "$(/path/to/bin/conda shell.bash hook)". The other shells work the same way, except for cmd.exe, where we jump through a bunch of different hoops. On Windows, we've put in code to let conda init start making registry modifications, if that's helpful here. Right now, the two modifications we're making are (1) making the conda command available to all cmd.exe shells (not just the "Anaconda Prompt") by setting HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun and (2) enabling HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled as the python.org python3.6 installers do.

The general strategy of keeping the bulk of the conda activate logic in python (specifically conda/activate.py) and making the shell parts as thin of wrapper as possible has proven so far to be stable and successful. Powershell is already built into the conda/activate.py file, although it may need some tweaking once it's actually being used. All shell activation tests are located in https://github.com/conda/conda/blob/710d30a9cc2e2417c00c0fcdc188eeff2216fb2f/tests/test_activate.py. We probably won't need any specific unit tests for powershell since they should already be written for the most part. We'll need to add an integration test or two in

conda/tests/test_activate.py

Lines 1255 to 1256 in 710d30a

	@pytest.mark.integration
	class ShellWrapperIntegrationTests(TestCase):

.

The integration tests use

conda/tests/test_activate.py

Line 1125 in 710d30a

class InteractiveShell(object):

which is a convenience wrapper around pexpect.

[kalefranz]

This PR was superseded by #7794

[github-actions]

Hi there, thank you for your contribution to Conda!

This pull request has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue or pull request if needed.