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

Detect virtual environment with different python versions. #388

Closed
wants to merge 1 commit into from
Closed

Conversation

proofit404
Copy link

Virtualenv site-packages will append to sys.path even if specified virtualenv has python version differs from version runs jedi.

This is a fix for my earlier issue #386.

Virtualenv site-packages will append to sys.path even if
specified virtualenv has python version differs from version
runs jedi.
@tkf
Copy link
Contributor

tkf commented Mar 20, 2014

What happen when the virtual environment has C extension modules *.so? Does it crash Python? Just import error?

I suggest to drop virtual environment support and treat it outside of Jedi (#385) since actual implementation is long if you want to treat all OS and all kinds of Python (#384 (comment)).

@proofit404
Copy link
Author

I test it in python only libraries, sorry. Can you point me at any *.so library so I can check this issues?

@ColinDuquesnoy
Copy link
Contributor

Can you point me at any *.so library so I can check this issues?

Threre are plenty of them. Here are few off the top of my head: numpy, PyQt, PySide, PyZMQ,...

@proofit404
Copy link
Author

Thanks, I'll test it against PyZMQ tomorrow.

@proofit404
Copy link
Author

Yes, this raise ImportError.

@proofit404 proofit404 closed this Mar 21, 2014
@tkf
Copy link
Contributor

tkf commented Mar 21, 2014

Honestly, ImportError is better than I exported :-) Maybe we can workaround by try-expect. But the problem is that C extension (*.so) in Python does not help un-importing module. So I don't know what would happen if you do: (1) import spam.so compiled for 3.3 into 2.7, which causes ImportError; (2) then import spam.so compiled for 2.7 into 2.7.

@tkf
Copy link
Contributor

tkf commented Mar 21, 2014

Wait, you can detect Python version from virtualenv path so maybe you can just use Jedi in "*.py-only mode" for these path. This way, you don't have *.so problem.

(But I still think it's better to remove virtualenv support from Jedi.)

@proofit404
Copy link
Author

Detect virtualenv throw environment variable seems unnecessary in jedi. So I consider removing it too.

@davidhalter
Copy link
Owner

@tkf You mean by implementing #385?

@tkf
Copy link
Contributor

tkf commented Mar 22, 2014

@davidhalter Which sentence you are talking about?

In case you are talking about:

(But I still think it's better to remove virtualenv support from Jedi.)

It's rather #384 (sys.path per Evaluator). If you can set sys.path then editors can use virtualenv.path_locations. On top of that, #385 would make it perfect since it solves C extension problem.

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

Successfully merging this pull request may close these issues.

4 participants