xonsh support

[kennethreitz]

we apparently don't work well on xonsh, according to @astronouth7303

[AstraLuma]

So, as a general rule: venv tools don't work on xonsh, because we have 0 bourne compatibility.

xonsh has its own tool called vox that manages, activates, and deactivates virtual envs in python. By default, it stores venvs in ~/.virtualenvs and will manage them when called.

I've written xontrib-avox that does this automatically based on the current working directory, matching the "project name" to available venvs.

The cool thing is that because avox uses vox, the vox command still works, vox-related events still fire, and any additional tools that integrate with vox still work. (At least, in theory. Our userbase is small and I'm not actually aware of any tools in this category. 😢 )

From a loose scan of the features and such, it looks like the only problem is pipenv shell, because xonsh is also python, so trying to call xonsh with a venv set is potentially problematic and unfortunately would need to be fixed on our end by redoing how we're packaged and called. (Potentially related to xonsh/xontrib-vox#5?) Otherwise, because there's no shell sourcing and nothing that needs to be added to rc files, I'm guessing pipenv doesn't do emit any bourne, and otherwise should work fine.

The thing I personaly would like to see is avox-style automatic detection of pipenv projects and doing appropriate activations, but there's an argument to be made for feature parity between shells.

[AstraLuma]

@laerus

[kennethreitz]

calling this out of scope for now.

[rca]

I've been happily using xonsh with pipenv shell --fancy for a number of months, and on a fresh install (Mac + homebrew + Python3.7 + pipenv + xonsh). I stumbled upon this issue after setting up a brand new machine and finding myself with a very broken pipenv shell.

It appears the new shell logic in 2018.7.1 doesn't work well with xonsh. The symptom is that an interactive program, say vi, within the pipenv shell will immediately background itself.

Downgrading to pipenv==2018.6.25 fixed the problem for me.

Thank you!

[uranusjr]

@rca This is likely because we switched the shell spawning backend in the latest release. Would you mind creating a separate issue to track this? Thanks for the help.

Also, to clarify—by your environment description, you installed Python 3 from Homebrew, but Pipenv and xonsh with pip (of the Homebrew Python 3). Am I correct? This information is relevant for recreating and tracing the problem.

---

Edit: Also I suspect this has something to do with the new logic uses os.exec instead of subprocess. This is the right choice almost all the time, but could lead to the shell being confused with complicated process hierarchy.

[rca]

I had made a pretty big mess the first time around, but am still able to repro with a cleaner install using the python.org 3.6 package.

I will elaborate in an issue under shellingham.

Thank you.