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

Python virtualenv wrapper fns - virtualenv vs venv #49

Open
sinewalker opened this issue Aug 30, 2018 · 3 comments
Open

Python virtualenv wrapper fns - virtualenv vs venv #49

sinewalker opened this issue Aug 30, 2018 · 3 comments

Comments

@sinewalker
Copy link
Owner

sinewalker commented Aug 30, 2018

I'm discovering as I play with Jupyter & matplotlib on a macOS machine, that virtualenv is suboptimal, because it copies Python binaries, which then are no longer macOS Frameworks, and so matplotlib doesn't work when called from inside another application such as a jupyter-enabled virtualenv.

Also tools like MS-VS Code seem to advocate the Python standard virtual environment system (since 3.6) of venv.

Also, I've been using "venv" in my bash fns as a short-hand for "virtualenv" (much like pipenv does, apparently) and so that'll be a bit confusing.

I need to rethink how / if my mkvenv, lsvenv, rmvenv fns work with virtualenv and venv; maybe switch them to venv and refactor the virtualenv-aware fns to mkpyv or something?

See:

@sinewalker
Copy link
Owner Author

sinewalker commented Aug 30, 2018

More points to note:

  • venv is only available in Python 3.5+, so if a project must use Python < 3.5, it must use virtualenv
  • venv has mixed reception, though it appears to be the "best" solution on macOS and the recommended solution for VS Code , Jupyter and matplotlib
  • virtualenv isn't going away any time soon, and pipenv is built around it. If pipenv has any merrit (which it seems on skimming that it does), then I may want to write tooling around both
  • I don't like the virtualenvwrapper stuff, that's why I wrote my fns in the first place
  • Where does Anaconda sit within all this? I think it's can remain on the side as it currently is handled by my existing fns.

@sinewalker
Copy link
Owner Author

sinewalker commented Jul 5, 2019

More notes:

This answer to the SO question above recommends venv over everything.

A work colleague recommends pyenv (yet another "only one obvious way to do it"). pyenv manages multiple Pythons much like rbenv/Node.js (forked from rbenv) and it has a plugin for virtualenv, called pyenv-virtualenv, which automatically will use python -m venv when available, and virtualenv is unavailable.

It also supports Anaconda/Miniconda.

Perhaps I should abandon my wrapperns or switch them to this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant