Question about virtual environments

[rpgoldman]

I'm using flycheck-pycheckers with a python file and have set the virtual environment appropriately using python-shell-virtualenv-root and flycheck-pycheckers-venv-root is also set correctly.

python-shell-virtualenv-root is a variable defined in ‘python.el’.

Its value is "/Users/rpg/.virtualenvs/ipyhopper/"
Original value was nil

However, flycheck-pycheckers does not seem to see this virtual environment, and complains that modules that are installed in the virtualenv cannot be found.

Is there something I need to do to tell flycheck-pycheckers about the current virtual environment? I see that the command is passed the virtual env root directory as a command line argument, but don't see how it knows which virtual environment in the root it should be using when checking a particular file.

Looking at pycheckers.py, I can see that there's a --venv-path argument, but nothing in flycheck-pycheckers.el uses that argument. Adding the following to my source file seems to work properly:

# Local Variables:
# flycheck-pycheckers-args: ("--venv-path" "/Users/rpg/.virtualenvs/ipyhopper")
# End:

Would it make sense to have a buffer-local variable like flycheck-pycheckers-venv-path that defaults to nil, and is passed to pycheckers.py? If you think this is a reasonable step to take, I could try to make a PR.

[msherry]

Hi there, and thanks for creating an issue!

It's true, the virtualenv handling of this package could use some love. I originally wrote this when I exclusively used virtual environments managed by virtualenvwrapper, so could count on a consistent set of conventions around how environments are managed. It looks like --venv-path was a start at fixing this, but as you've discovered, it's not complete yet. If you wanted to take a stab at fixing this issue, I would definitely be happy to take a look at it!

[rpgoldman]

Still haven't gotten around to fixing this, but haven't forgotten, either.

One follow-up question: the doc for flycheck-pycheckers-args says "This variable may be risky if used as a file-local variable." But actually, if one is working on python files in different projects in the same Emacs session, I would think that it would actually be almost necessary to make this variable buffer-local. Wondering what this warning is about. Is it a security thing? Is that what the "risky" refers to? Or is it "risky" in the sense of "you could make pycheckers work badly if you make this file-local"?

Thanks!

[msherry]

I believe it's because its value is passed to eval, so this could be risky if not under your control. This doesn't mean that one can't use it as a file-local variable, of course -- I believe it's just warning users not to trust this variable if set from outside their control.

[rpgoldman]

#71 takes advantage of existing emacs libraries tracking poetry virtual environments to pass through a pointer to those virtual environments, when available.

Small step towards extending coverage to the wild and wooly world of python virtual environments