Integration with pyvenv

[immerrr]

There's this package pyvenv that is basically an Emacs alternative to virtualenvwrapper with its pyvenv-activate command and its easier to use pyvenv-workon counterpart. I wonder if there's benefit in integrating pipenv.el with pyvenv or even offloading the activation command completely and use a more established package to do a thing as tricky as path management.

[pwalsh]

Hey @immerrr

All the path management in pyvenv is actually in the pythonic package. I did an earlier analysis of basing pipenv.el on Pythonic here. WDYT? If you come to a different conclusion to what I did then while doing the pipenv.el alpha, I am happy to reconsider.

[immerrr]

I don't think I can see any references between pythonic and pyvenv, could you elaborate a bit on

All the path management in pyvenv is actually in the pythonic package.

[pwalsh]

@immerrr oops, I confused it with https://github.com/proofit404/pyenv-mode

Still, I'm not sure how we can leverage pyvenv either, for similar reasons.

[immerrr]

pyvenv is about activating virtualenvs and managing environment related to them. pipenv creates and manages virtualenvs for projects automatically, but for activation you only have pipenv run and pipenv shell, but using them in Emacs everywhere is unwieldy.

I'm saying that when it's established that a project is pipenv-based, it's probably useful to provide convenient utilities to create & update that environment (piggybacking on the cmdline utility), and then just activating that environment via pyvenv and just letting pyvenv handle path modifications. There are a lot of subtleties in activating the settings and especially in rolling them back, it doesn't make much sense duplicating it.

For example, to ensure that all syntactic constructs work fine I prefer using flake8 & jedi installed in the --dev environment. You already recognize that some extra work must be done flake8, meaning that there's already a workaround to locate executables for flycheck. If you were to use pyvenv-activate and if it works as expected, workarounds like this won't be required at all. Or otherwise, if after pyvenv-activate flycheck still doesn't work, it's something to fix in pyvenv-flycheck interaction and the improvement would have a much wider target audience. Continuing, for jedi the workaround is not there yet. I suppose I could add project-wide variables to tweak jedi server command on per-project basis, or you could add another library-specific workaround, but IMHO that approach doesn't quite scale.

[pwalsh]

I'm saying that when it's established that a project is pipenv-based, it's probably useful to provide convenient utilities to create & update that environment (piggybacking on the cmdline utility), and then just activating that environment via pyvenv and just letting pyvenv handle path modifications. There are a lot of subtleties in activating the settings and especially in rolling them back, it doesn't make much sense duplicating it.

Ok. So basically replace https://github.com/pwalsh/pipenv.el/blob/master/pipenv.el#L337 with https://github.com/jorgenschaefer/pyvenv/blob/master/pyvenv.el#L158 and https://github.com/pwalsh/pipenv.el/blob/master/pipenv.el#L347 with https://github.com/jorgenschaefer/pyvenv/blob/master/pyvenv.el#L215

[immerrr]

Yep, that's the easy part.

The other would be to figure out a way to interact with pipfiles, or rather file- and directory-local settings. For pyvenv the majority of the use cases are easy: the user decides to what virtualenv they'd like to switch and when. However, there's this pyvenv-workon variable that could be used to switch virtualenvs automatically. I myself haven't used it though, so not sure how good it is, but given the automagical nature of pipenv that could be very relevant, too.

And I can easily see this feature being annoying if not executed properly. For example, non-file-based buffers don't inherit directory local variables ( despite having default-directory for which a dominating file could easily be found), so for process buffers to have pyvenv-workon variable one should add a change-major-mode-hook. Another problem could arise if you switch virtualenv upon entering directory project automatically: it saves you an invocation of emacs command, but it could become annoying if you switch between two projects with different virtualenvs frequently, so some balance should be found here. Perhaps, pyvenv-workon variable can provide some inspiration as well.

[Pilgrim1379]

Just to chime in here, my current work flow is to before I open any python file, M-x pyvenv-workon, this gives me a list of available virtual environments based on the WORKON_HOME environment variable. I have currently set my to /Users/username/.local/share/virtualenvs, which is where pipenv keeps is virtual environments on macos at least.

I then switch to the virtualenv of interest then access my python project files.

For me this is especially crucial as I have stared using the lsp-mode and lsp-python packages. It mandates that the python language server (pyls) is installed in the virtualenv before opening the first python file else it bails on you.

[pwalsh]

#45

[pwalsh]

Done in #48