poetry shell fails to set Python path if prompt uses VT100 escape sequences to read terminal information

[sliedes]

• Poetry version: 1.4.2
• Python version: 3.11.2
• OS version and name: Ubuntu 23.04

• I am on the latest stable Poetry version, installed using a recommended method.
• I have searched the issues of this repo and believe that this is not a duplicate.
• I have consulted the FAQ and blog for any relevant entries or release notes.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option) and have included the output below.

Issue

Related: #18 python-poetry/poetry#571

This is a result of me diagnosing why poetry shell starts a new shell, but without the virtual env activated.

Looking at how poetry uses the shell, it uses pexpect to run it, writing the command to activate the python environment as its first input. This breaks in all configurations that read anything before that; particularly, any configuration that uses VT100 escape sequences that read anything. These may be more or less common in, for example, prompts.

For example, I have this in my .bashrc, essentially from this StackOverflow comment:

new_line_ps1() {
    local _ y x _
    local LIGHT_YELLOW="\001\033[1;93m\002"
    local RESET="\001\e[0m\002"

    IFS='[;' read -p $'\e[6n' -d R -rs _ y x _

    if [[ "$x" != 1 ]]; then
        printf "\n${LIGHT_YELLOW}^^ no newline at end of output ^^\n${RESET}"
    fi
}

if [ "$color_prompt" = yes ]; then
    PS1='$(new_line_ps1)${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='$(new_line_ps1)${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

My analysis of what happens:

What this prompt does is it outputs the "\e[6n" VT100 escape code to read cursor position. VT100 compliant terminals respond to this by producing the a string like "\e[10;1R" as if input from a keyboard. This can then be read by the program to determine that the cursor is on line 10, column 1.

The way poetry shell is implemented, it typically claims to be VT100 compliant if run from such a terminal (because it does not change the TERM environment variable), yet it does not respond to VT100 queries the shell outputs before giving it the activation command. In this case, that results in the read command in the prompt reading (part of) the activation command.

[dimbleby]

poetry shell behaviour is pretty much all inherited from pexpect, you could try raising an issue over there - presumably you could reproduce this behaviour with pexpect and not using poetry at all.

Possibly pexpect isn't really meant to be used this way.

IMO poetry shell is a mis-step, more trouble than it's worth. If there's anything at all you don't like about poetry shell - you're better off ignoring it completely and just manually activating the virtual environment as you would have done if poetry shell had never existed.