pyenv-virtualenv | pyenv plugin to manage virtualenv | Build Tool library

I figured out how to run this environment, some of my steps were correct but I missed a few things.

So these are the correct install steps:
brew install pyenv
brew install virtualenv
brew install virtualenvwrapper

Then install the python version in pyenv, set it to global, and make sure your path sees this version of python first:
pyenv install 3.10.1
pyenv global 3.10.1
export PATH=/Users/myusername/.pyenv/shims:$PATH (keep in mind that you need to do this last command every time you start up another shell if you want your path to see the pyenv version of python first, unless you add the command to your .zshrc file)

Then
pyenv virtualenvwrapper (this is required for your terminal to see the virtualenvwrapper based commands)
mkvirtualenv my_venv

That should create the virtualenv in a way that is familiar with what you're used to using virtualenvwrapper. To activate this virtualenv in future sessions do:
pyenv virtualenvwrapper
workon my_venv

and to deactivate this environment simply type deativate

READ THE PYENV GUIDE CAREFULLY.

You didn't follow pyenv's README guide correctly. The guide tells you put PATH related operation in .bash_profile or .profile. But eval "$(pyenv init -)" in .bashrc.

Move pyenv init script from .bash_profile to .bashrc.

I don't use pyenv so I created this code after reading documentation and source code (not tested):

It appears the issue was that I had installed pyenv-virtualenv through brew instead of as a plugin. Running the following fixed the issue, as specified here:

Looks like you need to follow the suggested steps in the original error message

Update 2021-0602: After researching, experiencing, and googling more I found this article. It is detailed, opinionated in what I found a helpful way, and provided everything I was looking for and more. Highly recommend. Conda is quite different from venv.

Original Answer After researching and playing around, here's what I've found, particularly focused on the difference between conda environments and venv:

• High level, there's not that much of a difference between conda environments and venv. There are not large performance differences, time in setup differences, replication differences, etc.
• The decision to use one or the other should primarily by driven by personal preference, and the convention at work (e.g. if your work venv for everything, it probably makes sense to use venv and not conda environments.)

There are some differences worth calling out:

• Conda environments can set up environments for python and also R, so if you switch between the two conda is probably preferable so you only need to learn one set of tools/conventions.
• Conda environments all get stored in a single folder. This has pros and cons:
• Pro: you can easily look up all environments you've created.
• Pro: you can re-use one environment for multiple projects (e.g. I have a "finance" environment which works well for all my finance-related projects.)
• Con: you have to name all your environments differently, and remember the names (or look them up).
• Con: it is more of a pain to store that environment in the project folder you've created. This means you need to remember which environment goes with which project, and you can't simply cd into the project folder and then activate the generically named 'env' that is stored in that folder.

For the type of programming I'm doing, I find conda environments helpful. I could easily see use cases where venv is the better choice.

Lastly, Conda is both an environments manager as well as a package manager like PIP. Useful comparison table here.

In short, if you don't have a strong preference already, conda is more robust than venv or pip, can be combined with pip, and is probably the better default option. That said, if you already have a strong preference it means you likely already know how to do what you want, so it's unlikely to be worth it to change.

Like the error message says, you failed to perform an initialization which your shell login script usually does when you are using the shell yourself. The activation probably looks something like eval "$(pyenv init -)"; eval "$(pyenv virtualenv-init -)"; you can run that in your scripts stanza, too:

The problem was OpenSSL that was installed with Homebrew, but which "was not symlinked into /usr/local, because macOS provides LibreSSL." I learned this by running the command brew info openssl, which says

The issue seems to be due to a slight confusion between the name of the project (the thing that can be installed) and the name of the top level package (the thing that can be imported), with some case sensitivity issues adding to the confusion...

In that particular case the project is indeed named BoxSupDataset (that's what you want to install). But the actual top level package is boxsupdataset, which is the only thing that matters for the imports: