adds better windows shell support

[bmarroquin]

Pull Request Check List

This change resolves a lot duplicated issues.
Resolves: #5050, Resolves #4996, Resolves #4993, Resolves #4560, Resolves #2793, Resolves #2156, Resolves #1642

• Added tests for changed code.
• Updated documentation for changed code.

There are not tests for activating shells and this doesn't require a change in documentation. This lines up Windows behavior with the documentation.

[jrobbins-LiveData]

Subjective opinion: I like launching with -nologo to not have to see

PowerShell 7.2.1
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

each time.

[neersighted]

Given that it is cosmetic, I'd rather not add more arguments past the bare minimum, personally.

[jrobbins-LiveData]

Understood. It is definitely subjective on my part -- I like the "clean sheet" in front of me after typing poetry shell, but typing cls isn't a big deal.

[jrobbins-LiveData]

In my "wish list" for a nicer Windows cmd.exe experience in Poetry, there are only two items you didn't cover in your excellent PR.

1. command history (up/down arrow traversal of typed commands) in a Windows Terminal cmd.exe launched by poetry shell. This thread discusses the problem and offers a solution I have tested with poetry. If you added the following to Shell's __init__ method, using the implementation given in that thread for set_console_history_info(), you'd ensure that console command history will work in the Poetry shell. Without this, poetry shell inside Windows Terminal cmd.exe is markedly less usable.

        if WINDOWS:
            set_console_history_info()

2. this one is a more subjective "nice to have" feature: while executing the relevant activate script, it is nice to set the title of the console to the name of the folder. In the case of cmd.exe, this is simply adding via && another command to the args, e.g. "title", env.path.name. In the case of powershell/pwsh, it the added command includes '& {$host.UI.RawUI.WindowTitle = "%s"}' % env.path.name

[neersighted]

I'm a little leery of doing too much -- poetry shell is intentionally very minimal. This is a lesson learned from the pain and breakage that came from Pipenv's customized and curated, but ultimately brittle shell experience.

That being said, I'd still consider the suggestions made by @jrobbins-LiveData if they are added to this PR and don't look to be a big maintenance burden, since they seem to be minor and relatively stable.

[jrobbins-LiveData]

I agree, @neersighted, regarding the minimalist approach. Of all my feedback, I think I'd prioritize pwsh.exe support.

As to command history support, technically perhaps that's more properly a Windows Terminal concern. The reason I bring it up here is that if one "manually" simply runs Scripts\activate.bat in one's existing shell, one gets activation without losing command history because it is still the same shell. poetry shell, by necessity, launches a new shell, and so hits a Windows Terminal default limit, which is fixed by set_console_history_info().

In a regular command prompt window (not Windows Terminal), one can address this problem in its Properties page in the spot I've circled

[jrobbins-LiveData]

@neersighted , perhaps there could be an optional "user script" hook (configured via poetry's config mechanism?) , that the internal process.run would call inline if configured? This would allow for setting the title, configuring the command history buffer, etc, if the user wanted to configure the logic, without overly burdening the poetry code with taking on too much?

[bmarroquin]

@neersighted updated the PR. Only handled the changes that keep everything minimal.
There is a side effect that pwsh might work for non-windows environments. PR #5047 was trying to enable that. I did not test the change on non-windows environments.

@jrobbins-LiveData Thanks for all the feedback, appreciate it. I know this doesn't cover your wish list, but there are some minor upgrades 😊.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.