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

How to handle Python version differences? #17

Open
abingham opened this issue Nov 12, 2017 · 7 comments
Open

How to handle Python version differences? #17

abingham opened this issue Nov 12, 2017 · 7 comments

Comments

@abingham
Copy link
Owner

Our current system for starting servers is, in principle, too simple. We allow the user to specify a single virtualenv from which servers will be launched. Yet users could be working on Python 2 and Python 3 projects in the same emacs session.

What we want is some way to specify different traad/virtualenv versions for different projects. When starting a server, maybe could look for a .traad file telling us which version of the server to start. Or maybe we could keep something in .ropeproject, e.g. .ropeproject/traad.ini.

This leaves open the question of how these files are made in the first place...

@abingham
Copy link
Owner Author

I wonder if we could look for setup.py files and determine Python versions from the classifiers. This would be clever, though it's not a blanket solution...some projects simply won't have that information. It also leaves open the question of how to associate a Python major version with a virtualenv.

@shackra
Copy link

shackra commented Mar 17, 2018

I feel like this discussion can provide some light on the matter flycheck/flycheck#1055

@abingham
Copy link
Owner Author

abingham commented Mar 18, 2018

@shackra Can you give me the executive summary of that discussion? If it's simply "use python-shell-interpreter to run traad", then I don't think that'll work. It seems like that would require that traad be installed in every virtualenv where someone might want to use it; I was hoping to avoid that kind of requirement and allow users to install traad once (or once per major version).

@shackra
Copy link

shackra commented Mar 18, 2018

Can you give me the executive summary of that discussion?

I can't right now, sorry!

If it's simply "use python-shell-interpreter to run traad", then I don't think that'll work. It seems like that would require that traad be installed in every virtualenv where someone might want to use it; I was hoping to avoid that kind of requirement and allow users to install traad once (or once per major version).

I actually have a hook for venv that install jedi and other packages inside a new created virtual environment, but regarding your comment, is not there a way to inform traad of what version of python the user is using by checking the value of python-shell-interpreter? No need to install traad inside the virtual environment, just check the variable and start traad accordingly.

I'm too much words and not so much action, but that is my suggestion (I wish I could provide a proof of concept right here, but I don't have the time for that neither :(, hope you keep this issue open thus maybe I can provide something in the near future).

@abingham
Copy link
Owner Author

is not there a way to inform traad of what version of python the user is using by checking the value of python-shell-interpreter?

The python interpreter running traad needs to have traad and, critically, its dependencies available to it. So we can't just do python -m traad or something with the value of python-shell-interpreter. But maybe I'm missing something, so I'll keep this open.

@shackra
Copy link

shackra commented Mar 18, 2018

Wait, what I mean is like running the binary pointed by python-shell-interpreter and parse the output to inform traad what he should do next. Like imagine the value of the variable is python (/usr/bin/python):

$ python -V                                                                                                                        
Python 3.6.4

With traad, should have good enough information which major version it should caters to.

@abingham
Copy link
Owner Author

Ah, yes, we might be able to get that to work. This seems to work for python, ipython, and bpython:

python -c "import sys; print(sys.version)"

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

2 participants