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

xonsh support #498

Closed
kennethreitz opened this issue Sep 8, 2017 · 6 comments
Closed

xonsh support #498

kennethreitz opened this issue Sep 8, 2017 · 6 comments

Comments

@kennethreitz
Copy link
Contributor

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

@AstraLuma
Copy link

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
Copy link

@laerus

@kennethreitz
Copy link
Contributor Author

calling this out of scope for now.

@rca
Copy link

rca commented Aug 30, 2018

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
Copy link
Member

uranusjr commented Aug 30, 2018

@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
Copy link

rca commented Sep 2, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants