Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the purpose of the "poetry shell" command? #5050

Closed
jrobbins-LiveData opened this issue Jan 16, 2022 · 3 comments · Fixed by #5053
Closed

What is the purpose of the "poetry shell" command? #5050

jrobbins-LiveData opened this issue Jan 16, 2022 · 3 comments · Fixed by #5053

Comments

@jrobbins-LiveData
Copy link

jrobbins-LiveData commented Jan 16, 2022

I am using Poetry on Windows. While there are other issues open about the command prompt opened by poetry shell, I am unclear as to why Poetry needs to create a new shell in the first place? Why isn't it enough to activate the virtual environment?

What does poetry shell do, above and beyond what, e.g., .venv\scripts\activate does?

  • [ x] I have searched the issues of this repo and believe that this is not a duplicate.
  • [x ] I have searched the documentation and believe that my question is not covered.

Issue

I am using Poetry version 1.1.12 on Windows 10. I think I mostly understand the workflow(s) I need to use, with the exception of the poetry shell command. In a new project, poetry shell both creates the virtual environment and activates it. This is well-described by poetry shell --help

DESCRIPTION
  The shell command spawns a shell, according to the
  $SHELL environment variable, within the virtual environment.
  If one doesn't exist yet, it will be created.

I understand the need for a virtual environment. As a new poetry user, I was expecting a command to create a virtual environment and then a (possibly different) command to activate the virtual environment. Given that the shell created on Windows is really sub-optimal (no special $Prompt to remind me that the venv is active, no doskey command history, etc), it would seem to make sense to offer the two commands I was expecting.

Of course, I am new, and likely missing more than concern, so, also, I was hoping for guidance as to what the expected workflow is to get a new project going.

@finswimmer
Copy link
Member

Hello @jrobbins-LiveData,

poetry shell provides a shorthand to activate the virtual environment. By default Poetry doesn't create the venv within the project folder, but in {cache-dir}/virtualenvs. So using the activate script would require to find out the location of the venv everytime you want to activate it. With poetry shell you don't have to care about the location of the venv.

You are free to use this way of activated the venv or the activate script. :)

fin swimmer

@jrobbins-LiveData
Copy link
Author

Thank you! I have been configuring poetry to put the venv in my project folder, and so forgot all about the default scenario where the venv is "elsewhere".

I think I'd like to use poetry shell on Windows, if only it spawned a more functional shell (and hanging my head in shame, by "shell" I mean "cmd.exe". )

I think the two functional issues for this use-case are:

  1. poetry shell doesn't run pip's activate.bat, but instead sets the VIRTUAL_ENV and PATH environment variables without some of activate.bat's niceties (chief among them, using cmd.exe's prompt command to change the shell prompt by adding a (.venv) prefix to it. This prefix is very helpful to my aging brain to be reminded of the fact that a venv has been activated.
  2. Due to a somewhat arcane issue discussed here, when running cmd.exe as a tab inside Windows Terminal, the subprocess spawned cmd.exe lacks up/down arrow command history.

The solution at the bottom of that link does work, and I hacked my copy of poetry (in poetry/util/env.py) in the class VirtualEnv's execute method

    def execute(self, bin, *args, **kwargs):
        kwargs["env"] = self.get_temp_environ(environ=kwargs.get("env"))
        # TODO JSR
        if WINDOWS:
            print(get_console_history_info())
            print(set_console_history_info())
            print(get_console_history_info())
            return real_subprocess.run(["cmd.exe", "/E:ON", "/S", "/k", self._path / "scripts" / "activate.bat"], env=kwargs['env'])
        else:
            return super(VirtualEnv, self).execute(bin, *args, **kwargs)

as a quick proof-of-concept to see if I could address these two functional issues on Windows. It works, although obviously it is hardcoded for my choice of shell as cmd.exe and real code would need to respect the user's preference, among other improvements.

By running pip's activate.bat, I get my "fancy" Prompt, and by running set_console_history_info(), lifted from that linked post, I get a usable command window with up and down arrow traversing my command history.

I hope this all makes sense. It would be great to improve this aspect of poetry. Given the if WINDOWS flag already in place, I think these improvements could be made fairly safely, and not disrupt the experience of Linux users. What do you think?

Copy link

github-actions bot commented Mar 2, 2024

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

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants