up/down arrow history doesn't work on pipenv shell on windows

[crioux]

In the cmd shell, usually you can hit 'up arrow' to get your previous command. Once you run 'pipenv shell', this no longer works. if you run some commands inside the pipenv shell and then hit 'up' it does nothing.

[crioux]

FWIW, it works in 'ConEmu', just not the normal 'Windows Console Host' process that you get by running cmd.exe directly, so whatever they're doing in there to pass along the arrow keys is what you'd need. Not sure it's worth it to implement seperately in pipenv, but at least this is some kind of a workaround.

[erinxocon]

This is an issue with pew since it spawns the subshell on windows. Can you open an issue over there? I'm a maintainer of that project too and I'll make sure to address it on that project!
https://github.com/berdario/pew/issues

[askpatrickw]

This is still not in the patched PEW in this repo or in Pew directly, but I wanted to let others who end up here that if you use Powershell instead of the command prompt it does work.

[techalchemy]

(FYI in the next release -- which will be today -- we are no longer using pew for managing subshells).

[askpatrickw]

I tried installing from the repo and after I did pipenv shell, command history still didn't work. This is how I installed:

pip install git+https://github.com/pypa/pipenv
Collecting git+https://github.com/pypa/pipenv
  Cloning https://github.com/pypa/pipenv to c:\<snip>\appdata\local\temp\pip-req-build-yv19jpwg
  Installing build dependencies ... done
Requirement already satisfied: pip>=9.0.1 in c:\<snip>\python36\lib\site-packages (from pipenv==2018.7.1.dev0) (10.0.1)
Requirement already satisfied: certifi in c:\<snip>\python36\lib\site-packages (from pipenv==2018.7.1.dev0) (2018.4.16)
Requirement already satisfied: setuptools>=36.2.1 in c:\<snip>\python36\lib\site-packages (from pipenv==2018.7.1.dev0) (39.2.0)
Requirement already satisfied: virtualenv-clone>=0.2.5 in c:\<snip>\python36\lib\site-packages (from pipenv==2018.7.1.dev0) (0.3.0)
Requirement already satisfied: virtualenv in c:\<snip>\python36\lib\site-packages (from pipenv==2018.7.1.dev0) (16.0.0)
Installing collected packages: pipenv
  Running setup.py install for pipenv ... done
Successfully installed pipenv-2018.7.1.dev0

I tried it with an existing virtualenv and a newly recreated one. Let me know if I should try another branch.
Thanks!

[techalchemy]

Right this is a limitation of subshells in windows. There isn’t a fix for that and nobody is actively implementing one (this would effectively mean reimplementing subshells as far as I understand). Just sharing that pew is no longer involved in this aspect

[askpatrickw]

I keep seeing that said that, but with virtualenvwrapper-win workon <env> this works fine and I think its just batch files on top of virtualenv.

Virtualenvwrapper-win workon: https://github.com/davidmarble/virtualenvwrapper-win/blob/master/scripts/workon.bat

Worth noting: virtualenvwrapper-win does not support powershell it is mentioned there are versions which do, but I'm not sure which is the best so I won't link to one.

Maybe a pipenvwrapper-win needs to appear. But that would be sad I think.

If there are suggestions on approaches to fixing, I'm happy to take a swing, I just don't know this area well enough to do without a little guidance.

Thanks!

[uranusjr]

Just want to mention there is always pipenv run. Subshell-omg is by nature difficult to handle and has many platform restrictions. run is a better model unless you have a very subshell-friendly shell (e.g. fish).

[askpatrickw]

I'm intrigued, but I don't understand.

How would you use pipenv run to have your dev or run time environment available at the windows CLI or from an IDE launched from same?

[uranusjr]

I’m afraid I don’t quite understand the use cases you mentioned :( Could you be more specific what you think is the problem with run?

[askpatrickw]

I I see your point now (tried a few more things). When you pipenv run cmd you will have your environment available to you and you can launch your IDE from there as well. (VS Code: code .) and within VS Code in terminal you will also see all your pipenv installed resources as well.

AND your command history work (up arrow).

That seems like how it should work to begin with. I wonder if there are any downsides to this approach.

[techalchemy]

I can’t speak for everyone but I very rarely use subshells myself and I know @uranusjr doesn’t either. Since we are the main devs on the project following our workflow is most likely a safe bet