-
Notifications
You must be signed in to change notification settings - Fork 13
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
Turn pyenv-mode into a local mode and introduce global-pyenv-mode #30
Conversation
New global `pyenv-mode` will use projectile to set up PYENV_VERSION automatically.
Hi, Personally, I don't like that I can't use switch key bindings from dired, shell or compilation modes. Will projectile-style keymap prefix solve your issue? If you have This mode is useful if you do not have What do you think? |
We can extract the condition in
Not if you are on OSX, in which the GUI doesn't inherit the shell's environment, and don't want to reinvent all the logic in
Also not true, projects like powerline and Spacemacs use |
Also, as a result, if you don't look at a .python-version file first, you may activate the wrong virtualenv or not at all if you are just looking at the project name. |
This already solved by Mention this in README is ok. |
I like to make projectile as optional as possible. Second README snippet is ok. |
Ok how about this: pyenv should detect whether a
It is already optional, see the |
After some time thinking about this I came to this decision:
What do you think? |
Hi!
I've finally fixed this issue that's been bothering me for a while.
Currently,
pyenv-mode
is a global minor mode but not the conventional kind setup withdefine-globalized-minor-mode
. It has a global keymap that clobbersre-builder
but doesn't offer any help integrating with Projectile satisfactorily.This PR turns the original
pyenv-mode
topyenv-local-mode
, the newpyenv-mode
will now only turn onpyenv-local-mode
and its associated keybindings only onpython
mode buffers.In addition, the new global
pyenv-mode
will integrate with Projectile much more reliably than what's currently written on the README. In addition to trying to match the project name with a pyenv installed python version, it will first look at the project root and use the python version defined in the.python-version
file instead.I've taken care of not breaking backward compatibility in the PR. Ideally I'd like to only prefix all the variables and functions with
pyenv
instead ofpyenv-mode
, as per convention, but that's probably a bit too much cos I'll have to deprecate everything...Hope you like this!