Skip to content

Instantly share code, notes, and snippets.

@Geoyi

Geoyi/python_environment_setup.md

Forked from wronk/python_environment_setup.md
Created January 20, 2018 19:01
Show Gist options
  • Save Geoyi/f55ed54d24cc9ff1c14bd95fac21c042 to your computer and use it in GitHub Desktop.
Save Geoyi/f55ed54d24cc9ff1c14bd95fac21c042 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. @wronk wronk revised this gist Jan 19, 2018. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -72,11 +72,11 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    1. If you have file not found issues with pyenv's `virtualenvwrapper.sh`, you should be able to check where it lives with `pyenv which virtualenvwrapper.sh`
    ## Other notes
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because the Anaconda software distribution contains both the `conda` package manager as well as many useful python modules, which is great for new Python users. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on Windows. However, there are some downsides to Anaconda/`conda`:
    1. **Anaconda** does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because the Anaconda software distribution contains both the `conda` package manager as well as many useful python modules, which is great for new Python users. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on Windows. However, there are some downsides to Anaconda/`conda`:
    * Any package that can't be installed via the `conda` package manager must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of modules because Continuum must repackage each one into their own system before calling `conda update` will actually provide the newest version of that module's code.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because the Anaconda software distribution is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree as it only contains the `conda` package manager and it's dependencies.
    * Because the Anaconda software distribution is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree as it only contains the `conda` package manager and its dependencies.
    That aside, a good discussion of Anaconda's benefits, and some counter-arguements are [here](http://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/#Myth-#5:-conda-doesn't-work-with-virtualenv,-so-it's-useless-for-my-workflow).
  2. @wronk wronk revised this gist Jan 19, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -78,7 +78,7 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because the Anaconda software distribution is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree as it only contains the `conda` package manager and it's dependencies.
    That aside, a good discussion of Anaconda's benefits, and some counter-arguements are [here](http://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/#Myth-#5:-conda-doesn't-work-with-virtualenv,-so-it's-useless-for-my-workflow).
    That aside, a good discussion of Anaconda's benefits, and some counter-arguements are [here](http://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/#Myth-#5:-conda-doesn't-work-with-virtualenv,-so-it's-useless-for-my-workflow).
    1. **Virtual environment prefix on source prompt**
  3. @wronk wronk revised this gist Jan 19, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -78,7 +78,7 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because the Anaconda software distribution is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree as it only contains the `conda` package manager and it's dependencies.
    That aside, a good discussion of Anaconda's benefits, and some counter-arguements are [here](http://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/#Myth-#5:-conda-doesn't-work-with-virtualenv,-so-it's-useless-for-my-workflow).
    That aside, a good discussion of Anaconda's benefits, and some counter-arguements are [here](http://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/#Myth-#5:-conda-doesn't-work-with-virtualenv,-so-it's-useless-for-my-workflow).
    1. **Virtual environment prefix on source prompt**
  4. @wronk wronk revised this gist Jan 19, 2018. 1 changed file with 2 additions and 0 deletions.
    2 changes: 2 additions & 0 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -77,6 +77,8 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    * You aren't always going to be using the most up-to-date version of modules because Continuum must repackage each one into their own system before calling `conda update` will actually provide the newest version of that module's code.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because the Anaconda software distribution is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree as it only contains the `conda` package manager and it's dependencies.
    That aside, a good discussion of Anaconda's benefits, and some counter-arguements are [here](http://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/#Myth-#5:-conda-doesn't-work-with-virtualenv,-so-it's-useless-for-my-workflow).
    1. **Virtual environment prefix on source prompt**
  5. @wronk wronk revised this gist Jan 19, 2018. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,12 +1,12 @@
    ## Overview
    When you're working on multiple coding projects, you might want a couple different version of Python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of Python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda). See the [Using the workflow](https://gist.github.com/wronk/a902185f5f8ed018263d828e1027009b#using-the-workflow) section to view the end result.
    When you're working on multiple coding projects, you might want a couple different version of Python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of Python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a package manager like `conda`). See the [Using the workflow](https://gist.github.com/wronk/a902185f5f8ed018263d828e1027009b#using-the-workflow) section to view the end result.

    ### Use cases
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2.7 project and a Python 3.6 project, or developing a module that needs to work across multiple versions of Python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    2. If you want to execute code on the cloud, you can set up a Python environment that mirrors the relevant cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    3. You might have some working Python code and want to make sure everything stays frozen so that it'll still work in the future. Without virtual environments, upgrading Python modules could unintentionally break that year-old project. Having to go back and determine the correct version for each dependency would be a huge pain.

    This guide shows how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It shows how to obtain lower-level control of your development environment (compared to Anaconda, for example) without too much technical complication. This is intended for MacOS, but all the tools work on Unix-like systems -- you'll just have to make use of `apt-get` instead of `brew` and detour through the original installation guides in some spots.
    This guide shows how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It shows how to obtain lower-level control of your development environment (compared to Anaconda/`conda`, for example) without too much technical complication. This is intended for MacOS, but all the tools work on Unix-like systems -- you'll just have to make use of `apt-get` instead of `brew` and detour through the original installation guides in some spots.

    For comparison to Anaconda, see [note below](#other-notes)

    @@ -72,7 +72,7 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    1. If you have file not found issues with pyenv's `virtualenvwrapper.sh`, you should be able to check where it lives with `pyenv which virtualenvwrapper.sh`
    ## Other notes
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because the Anaconda software distribution contains both the `conda` package manager as well as many useful python modules, which is great for new Python users. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on Windows. However, there are some downsides to Anaconda:
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because the Anaconda software distribution contains both the `conda` package manager as well as many useful python modules, which is great for new Python users. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on Windows. However, there are some downsides to Anaconda/`conda`:
    * Any package that can't be installed via the `conda` package manager must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of modules because Continuum must repackage each one into their own system before calling `conda update` will actually provide the newest version of that module's code.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
  6. @wronk wronk revised this gist Jan 19, 2018. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -72,11 +72,11 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    1. If you have file not found issues with pyenv's `virtualenvwrapper.sh`, you should be able to check where it lives with `pyenv which virtualenvwrapper.sh`
    ## Other notes
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system before calling `conda update` will actually provide the newest version.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because the Anaconda software distribution contains both the `conda` package manager as well as many useful python modules, which is great for new Python users. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on Windows. However, there are some downsides to Anaconda:
    * Any package that can't be installed via the `conda` package manager must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of modules because Continuum must repackage each one into their own system before calling `conda update` will actually provide the newest version of that module's code.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because the Anaconda software distribution is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree as it only contains the `conda` package manager and it's dependencies.
    1. **Virtual environment prefix on source prompt**
  7. @wronk wronk revised this gist Jan 8, 2018. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@ When you're working on multiple coding projects, you might want a couple differe
    2. If you want to execute code on the cloud, you can set up a Python environment that mirrors the relevant cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    3. You might have some working Python code and want to make sure everything stays frozen so that it'll still work in the future. Without virtual environments, upgrading Python modules could unintentionally break that year-old project. Having to go back and determine the correct version for each dependency would be a huge pain.

    This guide will show you how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It is intended mostly for Unix-like systems (e.g., MacOS and Linux) and provides a good approach to gain lower-level control of your development environment (compared to Anaconda, for example) without too much technical complication.
    This guide shows how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It shows how to obtain lower-level control of your development environment (compared to Anaconda, for example) without too much technical complication. This is intended for MacOS, but all the tools work on Unix-like systems -- you'll just have to make use of `apt-get` instead of `brew` and detour through the original installation guides in some spots.

    For comparison to Anaconda, see [note below](#other-notes)

    @@ -42,7 +42,7 @@ For comparison to Anaconda, see [note below](#other-notes)
    # Tell pyenv-virtualenvwrapper to use pyenv when creating new Python environments
    export PYENV_VIRTUALENVWRAPPER_PREFER_PYVENV="true"
    ```
    Make sure that the directory you define for `WORKON_HOME` actually exists, and then either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full virtualenvwrapper [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    Make sure that the directory you define for `WORKON_HOME` actually exists, and check that tthen either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full virtualenvwrapper [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    ## Using the workflow
    @@ -70,7 +70,7 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    Make sure you have newest version of XCode CLI installed by running: `xcode-select --install`
    1. If you have file not found issues with pyenv's `virtualenvwrapper.sh`, you should be able to check where it lives with `pyenv which virtualenvwrapper.sh`
    ## Other notes
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
  8. @wronk wronk revised this gist Jan 8, 2018. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -8,7 +8,7 @@ When you're working on multiple coding projects, you might want a couple differe

    This guide will show you how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It is intended mostly for Unix-like systems (e.g., MacOS and Linux) and provides a good approach to gain lower-level control of your development environment (compared to Anaconda, for example) without too much technical complication.

    For comparison to Anaconda, see [note below](#Other Notes)
    For comparison to Anaconda, see [note below](#other-notes)

    ## Overview of the tools and setup
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "Python environment." This manages which version of Python is visible to your computer (and temporarily hides any others). With pyenv, you can install multiple versions of Python and quickly switch between the "activated" version (i.e., the version your computer will use to execute code). Here, we'll switch the version of Python we're using with virtualenvwrapper's `workon` command (as described later).
    @@ -73,10 +73,10 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ## Other notes
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system before calling `conda update` will actually provide the newest version.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system before calling `conda update` will actually provide the newest version.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.
    1. **Virtual environment prefix on source prompt**
  9. @wronk wronk revised this gist Jan 8, 2018. 1 changed file with 18 additions and 6 deletions.
    24 changes: 18 additions & 6 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -8,12 +8,7 @@ When you're working on multiple coding projects, you might want a couple differe

    This guide will show you how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It is intended mostly for Unix-like systems (e.g., MacOS and Linux) and provides a good approach to gain lower-level control of your development environment (compared to Anaconda, for example) without too much technical complication.

    **Note on Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system before calling `conda update` will actually provide the newest version.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.

    For comparison to Anaconda, see [note below](#Other Notes)

    ## Overview of the tools and setup
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "Python environment." This manages which version of Python is visible to your computer (and temporarily hides any others). With pyenv, you can install multiple versions of Python and quickly switch between the "activated" version (i.e., the version your computer will use to execute code). Here, we'll switch the version of Python we're using with virtualenvwrapper's `workon` command (as described later).
    @@ -65,7 +60,24 @@ workon # List the environments available
    workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ```
    ## Troubleshooting
    1. If you're on MacOS and have issues with pyenv like:
    ```
    zipimport.ZipImportError: can't decompress data; zlib not available
    make: *** [install] Error 1
    pyenv: version `3.5.0' is not installed
    ```
    Make sure you have newest version of XCode CLI installed by running: `xcode-select --install`
    ## Other notes
    1. **Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system before calling `conda update` will actually provide the newest version.
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.
    1. **Virtual environment prefix on source prompt**
    If you want your command prompt to show the virtual environment you're currently working with, add this to you .bashrc/.bash_profile:
  10. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -66,17 +66,17 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ```
    ## Other notes
    1. **Environment Prefix on source prompt**
    1. **Virtual environment prefix on source prompt**
    If you want your command prompt to show the environment you're currently working with, add this to you .bashrc/.bash_profile:
    If you want your command prompt to show the virtual environment you're currently working with, add this to you .bashrc/.bash_profile:
    ```
    # Prefix source prompt with virtualenvwrapper environment
    if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
    eval "$(pyenv virtualenv-init -)"
    ```
    The command prompt will now look something like `(my_project_py3) Mark@Marks-MBP:~/Builds/ $`
    Your terminal command prompt will now look something like `(my_project_py3) Mark@Marks-MBP:~/Builds/ $`
    1. **Directory scheme**
  11. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 19 additions and 19 deletions.
    38 changes: 19 additions & 19 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,31 +1,31 @@
    ## Overview
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda). See the [Using the workflow](https://gist.github.com/wronk/a902185f5f8ed018263d828e1027009b#using-the-workflow) section to view the end result.
    When you're working on multiple coding projects, you might want a couple different version of Python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of Python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda). See the [Using the workflow](https://gist.github.com/wronk/a902185f5f8ed018263d828e1027009b#using-the-workflow) section to view the end result.

    ### Use cases
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2.7 project and a Python 3.6 project, or developing a module that needs to work across multiple versions of python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    2. If you want to execute code on the cloud, you can set up a python environment that mirrors the relevant cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    3. You might have some working python code and want to make sure everything stays frozen so that it'll still work in the future. Without virtual environments, upgrading python modules could unintentionally break that year-old project. Having to go back and determine the correct version for each dependency would be a huge pain.
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2.7 project and a Python 3.6 project, or developing a module that needs to work across multiple versions of Python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    2. If you want to execute code on the cloud, you can set up a Python environment that mirrors the relevant cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    3. You might have some working Python code and want to make sure everything stays frozen so that it'll still work in the future. Without virtual environments, upgrading Python modules could unintentionally break that year-old project. Having to go back and determine the correct version for each dependency would be a huge pain.

    This guide will show you how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It is intended mostly for Unix-like systems (e.g., MacOS and Linux) and provides a good approach to gain lower-level control of your development environment (compared to Anaconda, for example) without too much technical complication.

    **Note on Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    **Note on Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all Python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system before calling `conda update` will actually provide the newest version.
    * Different versions of python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Different versions of Python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.


    ## Overview of the tools and setup
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "python environment." This manages which version of python is visible to your computer (and temporarily hides any others). With pyenv, you can install multiple versions of python and quickly switch between the "activated" version (i.e., the version your computer will use to execute code). Here, we'll switch the version of python we're using with virtualenvwrapper's `workon` command (as described later).
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "Python environment." This manages which version of Python is visible to your computer (and temporarily hides any others). With pyenv, you can install multiple versions of Python and quickly switch between the "activated" version (i.e., the version your computer will use to execute code). Here, we'll switch the version of Python we're using with virtualenvwrapper's `workon` command (as described later).

    **Installation/use**: `brew install pyenv` on Mac. Also install [pyenv-virtualenv](https://github.com/pyenv/pyenv-virtualenv) like `brew install pyenv-virtualenv`, which we'll need later. See the docs for installation via `git clone` on other other systems. Then you can install new python versions, list installed versions, and set the python version in the terminal like:
    **Installation/use**: `brew install pyenv` on Mac. Also install [pyenv-virtualenv](https://github.com/pyenv/pyenv-virtualenv) like `brew install pyenv-virtualenv`, which we'll need later. See the docs for installation via `git clone` on other other systems. Then you can install new Python versions, list installed versions, and set the Python version in the terminal like:
    ```
    pyenv install 3.6.3 # Install python version
    pyenv install 3.6.3 # Install Python version
    pyenv install 3.4.0
    pyenv versions # List python versions
    pyenv global 3.6.3 # Set your system's python version
    pyenv versions # List Python versions
    pyenv global 3.6.3 # Set your system's Python version
    ```
    **Technical details**: Every time you execute a python script or use pip, pyenv works in the background to intercept that command and send it to the python environment that is currently activated. It does this using shims on the PATH environment variable, which allow python-related commands to be dynamically rerouted.
    **Technical details**: Every time you execute a Python script or use pip, pyenv works in the background to intercept that command and send it to the Python environment that is currently activated. It does this using shims on the PATH environment variable, which allow Python-related commands to be dynamically rerouted.
    2. **[virtualenv](https://virtualenv.pypa.io/en/stable/)**: Short for "virtual environment." This manages separate directories for the modules you install (e.g., with `pip`). That way, each virtual environment can have it's own set of installed modules that is walled off from every other virtual environment so they don't interfere with each other. Like with pyenv, we'll switch virtual environments with virtualenvwrapper's `workon` command (as described later).
    @@ -36,28 +36,28 @@ This guide will show you how to solve these issues with pyenv and virtualenv (al
    **Technical details**: virtualenv keeps each environment (and its installed modules) in separate folders; therefore, each is like a silo that doesn't interact with any other virtual environment. Usually, the exact file location is defined by the user, but we can use virtualenvwrapper to instead handle this for us.
    3. **[virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/)**. This helps pyenv and virtualenv gel like PB&J. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    3. **[virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/)**. This helps pyenv and virtualenv gel like PB&J. With it, you can effectively switch between a single environment that has both the Python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    **Installation**: `pip install virtualenvwrapper` and then `brew install pyenv-virtualenvwrapper` to extend pyenv. Then you'll need to do some one-time setup; in your .bashrc/.bash_profile, add the following:
    ```
    # Setup virtualenv home
    export WORKON_HOME=$HOME/.virtualenvs
    source /usr/local/bin/virtualenvwrapper.sh
    # Tell pyenv-virtualenvwrapper to use pyenv when creating new python environments
    # Tell pyenv-virtualenvwrapper to use pyenv when creating new Python environments
    export PYENV_VIRTUALENVWRAPPER_PREFER_PYVENV="true"
    ```
    Make sure that the directory you define for `WORKON_HOME` actually exists, and then either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full virtualenvwrapper [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    ## Using the workflow
    We're all ready to use this in the terminal! First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    We're all ready to use this in the terminal! First, we'll set the Python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    ```
    pyenv global 3.6.3 # Set your system's python version with pyenv
    pyenv global 3.6.3 # Set your system's Python version with pyenv
    mkvirtualenv my_project_py3 # Create a new virtual environment using virtualenvwrapper; it'll be tied to Python 3.6.3
    pip install numpy scipy # Install the packages you want in this environment

    pyenv global 2.7.0 # Set your system's python version with pyenv
    pyenv global 2.7.0 # Set your system's Python version with pyenv
    mkvirtualenv webdev_py2 # Create/switch to a new virtual environment; it'll use Python 2.7.0
    pip install flask boto

    @@ -80,6 +80,6 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    1. **Directory scheme**
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    This is my own personal preference, but when setting up my Python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable in my .bashrc/.bash_profile (e.g., named `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/Python code is more agnostic of the exact machine I'm using.
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to look cleaner in code and is easier for getting the same code running locally and on the cloud (or another computer).
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in Python code so it'll work on any machine that mirrors my directory scheme. That tends to look cleaner in code and is easier for getting the same code running locally and on the cloud (or another computer).
  12. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 4 additions and 2 deletions.
    6 changes: 4 additions & 2 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -67,7 +67,8 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ## Other notes
    1. **Environment Prefix on source prompt**
    If you want your command prompt to show the environment you're currently working with, add this to you .bashrc/.bash_profile:
    If you want your command prompt to show the environment you're currently working with, add this to you .bashrc/.bash_profile:
    ```
    # Prefix source prompt with virtualenvwrapper environment
    @@ -78,6 +79,7 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    The command prompt will now look something like `(my_project_py3) Mark@Marks-MBP:~/Builds/ $`
    1. **Directory scheme**
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to look cleaner in code and is easier for getting the same code running locally and on the cloud (or another computer).
  13. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -66,8 +66,8 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ```
    ## Other notes
    1. Environment Prefix on source prompt
    If you want your command prompt to show the environment you're currently working with, add this to you .bashrc/.bash_profile:
    1. **Environment Prefix on source prompt**
    If you want your command prompt to show the environment you're currently working with, add this to you .bashrc/.bash_profile:
    ```
    # Prefix source prompt with virtualenvwrapper environment
    @@ -77,7 +77,7 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    The command prompt will now look something like `(my_project_py3) Mark@Marks-MBP:~/Builds/ $`
    1. Directory scheme
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    1. **Directory scheme**
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to look cleaner in code and is easier for getting the same code running locally and on the cloud (or another computer).
  14. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 4 additions and 5 deletions.
    9 changes: 4 additions & 5 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -18,7 +18,7 @@ This guide will show you how to solve these issues with pyenv and virtualenv (al
    ## Overview of the tools and setup
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "python environment." This manages which version of python is visible to your computer (and temporarily hides any others). With pyenv, you can install multiple versions of python and quickly switch between the "activated" version (i.e., the version your computer will use to execute code). Here, we'll switch the version of python we're using with virtualenvwrapper's `workon` command (as described later).

    **Installation/use**: `brew install pyenv` on Mac. Also install [pyenv-virtualenv](https://github.com/pyenv/pyenv-virtualenv) like `brew install pyenv-virtualenv`, which we'll need later. See the docs for installation via `git clone` on other other systems. Then you can install new python versions, list installed versions, and set the python version like:
    **Installation/use**: `brew install pyenv` on Mac. Also install [pyenv-virtualenv](https://github.com/pyenv/pyenv-virtualenv) like `brew install pyenv-virtualenv`, which we'll need later. See the docs for installation via `git clone` on other other systems. Then you can install new python versions, list installed versions, and set the python version in the terminal like:
    ```
    pyenv install 3.6.3 # Install python version
    pyenv install 3.4.0
    @@ -30,7 +30,7 @@ This guide will show you how to solve these issues with pyenv and virtualenv (al
    2. **[virtualenv](https://virtualenv.pypa.io/en/stable/)**: Short for "virtual environment." This manages separate directories for the modules you install (e.g., with `pip`). That way, each virtual environment can have it's own set of installed modules that is walled off from every other virtual environment so they don't interfere with each other. Like with pyenv, we'll switch virtual environments with virtualenvwrapper's `workon` command (as described later).
    **Installation**:
    `pip install virtualenv`
    `pip install virtualenv` in your terminal
    **Use:** It's possible to use virtualenv directly as ([as described here](https://virtualenv.pypa.io/en/stable/userguide/)), but we'll use virtualenvwrapper instead.
    @@ -51,7 +51,7 @@ This guide will show you how to solve these issues with pyenv and virtualenv (al
    ## Using the workflow
    We're all ready! First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    We're all ready to use this in the terminal! First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    ```
    pyenv global 3.6.3 # Set your system's python version with pyenv
    mkvirtualenv my_project_py3 # Create a new virtual environment using virtualenvwrapper; it'll be tied to Python 3.6.3
    @@ -80,5 +80,4 @@ workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    1. Directory scheme
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to look cleaner in code and is easier for getting the same code running locally and on the cloud (or another computer).
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to look cleaner in code and is easier for getting the same code running locally and on the cloud (or another computer).
  15. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,5 @@
    ## Overview
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda). See the
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda). See the [Using the workflow](https://gist.github.com/wronk/a902185f5f8ed018263d828e1027009b#using-the-workflow) section to view the end result.

    ### Use cases
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2.7 project and a Python 3.6 project, or developing a module that needs to work across multiple versions of python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
  16. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 15 additions and 13 deletions.
    28 changes: 15 additions & 13 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,5 +1,5 @@
    ## Overview
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda).
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda). See the

    ### Use cases
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2.7 project and a Python 3.6 project, or developing a module that needs to work across multiple versions of python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    @@ -48,20 +48,22 @@ This guide will show you how to solve these issues with pyenv and virtualenv (al
    export PYENV_VIRTUALENVWRAPPER_PREFER_PYVENV="true"
    ```
    Make sure that the directory you define for `WORKON_HOME` actually exists, and then either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full virtualenvwrapper [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    **Use:** First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    ```
    pyenv global 3.6.3 # Set your system's python version with pyenv
    mkvirtualenv my_project_py3 # Create a new virtual environment using virtualenvwrapper; it'll be tied to Python 3.6.3
    pip install numpy scipy # Install the packages you want in this environment
    pyenv global 2.7.0 # Set your system's python version with pyenv
    mkvirtualenv webdev_py2 # Create/switch to a new virtual environment; it'll use Python 2.7.0
    pip install flask boto
    workon # List the environments available
    workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ```
    ## Using the workflow
    We're all ready! First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    ```
    pyenv global 3.6.3 # Set your system's python version with pyenv
    mkvirtualenv my_project_py3 # Create a new virtual environment using virtualenvwrapper; it'll be tied to Python 3.6.3
    pip install numpy scipy # Install the packages you want in this environment

    pyenv global 2.7.0 # Set your system's python version with pyenv
    mkvirtualenv webdev_py2 # Create/switch to a new virtual environment; it'll use Python 2.7.0
    pip install flask boto

    workon # List the environments available
    workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ```
    ## Other notes
    1. Environment Prefix on source prompt
  17. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -10,7 +10,7 @@ This guide will show you how to solve these issues with pyenv and virtualenv (al

    **Note on Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system before calling `conda update` will actually provide the newest version.
    * Different versions of python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.

  18. @wronk wronk revised this gist Jan 3, 2018. 1 changed file with 18 additions and 9 deletions.
    27 changes: 18 additions & 9 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,17 +1,24 @@
    ## Overview
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different needs) on your default computer system. Concrete examples of this situation:
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different dependencies) on your system's version of python. This intermediate guide covers one way to handle multiple Python versions and Python environments on your own (i.e., without a manager like Anaconda).

    ### Use cases
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2 project and a Python 3 project, or building a module that needs to work across multiple versions of python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2.7 project and a Python 3.6 project, or developing a module that needs to work across multiple versions of python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    2. If you want to execute code on the cloud, you can set up a python environment that mirrors the relevant cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    3. You might have some working python code and want to make sure everything stays frozen so that it'll still work in the future. Without virtual environments, upgrading python modules could unintentionally break that year-old project. Having to go back and determine the correct version for each dependency would be a huge pain.

    If some of your required libraries don't work with Anaconda, pyenv and virtualenv (along with virtualenvwrapper) are a good approach to gain lower-level control without too much technical complication. Note, however, that there are **a lot** more ways to make your workflow fancier and more efficient. This guide covers what pyenv, virtualenv, and virtualenvwrapper are, how they're installed/used, and how they fit together.
    This guide will show you how to solve these issues with pyenv and virtualenv (along with virtualenvwrapper). It is intended mostly for Unix-like systems (e.g., MacOS and Linux) and provides a good approach to gain lower-level control of your development environment (compared to Anaconda, for example) without too much technical complication.

    **Note on Anaconda**: Anaconda does have functionality to handle some of the problems outlined above. Generally, it provides a lower bar for entry to Python development because everything is self-contained in one install, which is great to new programmers or those new to Python. Anaconda is also a good choice for Windows users as getting all python packages to play nicely together is a challenge on that OS. However, there are some downsides to Anaconda:
    * Any package that isn't included in conda must be installed with pip or some other method; at that point, you're managing two install streams. For more advanced development, this can get messy.
    * You aren't always going to be using the most up-to-date version of libraries because they Anaconda must repackage them into their own system.
    * Different versions of python will not always have the latest module updates -- Continuum focuses its resources on Python 2.7 and 3.6 right now, and you're relying on their team to incorporate all package updates to those version as well as the less-popular versions (like 3.4 and 3.5).
    * Because Anaconda is a large self-contained install, it'll install many packages that you might not need. Miniconda solves this to some degree.


    ## Overview of the tools and setup
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "python environment." This manages which version of python is visible to your computer (and temporarily hides any others). With pyenv, you can install multiple versions of python and quickly switch between the "activated" version (i.e., the version your computer will use to execute code). Here, we'll switch the version of python we're using with virtualenvwrapper's `workon` command (as described later).

    **Installation/use**: `brew install pyenv` on Mac. See the docs for installation via `git clone` on other other systems. Then you can install new python versions, list installed versions, and set the python version like:
    **Installation/use**: `brew install pyenv` on Mac. Also install [pyenv-virtualenv](https://github.com/pyenv/pyenv-virtualenv) like `brew install pyenv-virtualenv`, which we'll need later. See the docs for installation via `git clone` on other other systems. Then you can install new python versions, list installed versions, and set the python version like:
    ```
    pyenv install 3.6.3 # Install python version
    pyenv install 3.4.0
    @@ -31,13 +38,16 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    3. **[virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/)**. This helps pyenv and virtualenv gel like PB&J. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    **Installation**: `pip install virtualenvwrapper` and then you'll need to do some one-time setup; in your .bashrc/.bash_profile, create the bash environment variable `WORKON_HOME` and source the virtualenv wrapper script:
    **Installation**: `pip install virtualenvwrapper` and then `brew install pyenv-virtualenvwrapper` to extend pyenv. Then you'll need to do some one-time setup; in your .bashrc/.bash_profile, add the following:
    ```
    #virtualenv
    # Setup virtualenv home
    export WORKON_HOME=$HOME/.virtualenvs
    source /usr/local/bin/virtualenvwrapper.sh
    # Tell pyenv-virtualenvwrapper to use pyenv when creating new python environments
    export PYENV_VIRTUALENVWRAPPER_PREFER_PYVENV="true"
    ```
    Make sure that the directory you define for `WORKON_HOME` actually exists, and then either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    Make sure that the directory you define for `WORKON_HOME` actually exists, and then either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full virtualenvwrapper [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    **Use:** First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    ```
    @@ -61,13 +71,12 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    # Prefix source prompt with virtualenvwrapper environment
    if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
    eval "$(pyenv virtualenv-init -)"
    export PYENV_VIRTUALENVWRAPPER_PREFER_PYVENV="true"
    ```
    The command prompt will now look something like `(my_project_py3) Mark@Marks-MBP:~/Builds/ $`
    1. Directory scheme
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to be easier for getting the same code running locally and on the cloud (or another computer).
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to look cleaner in code and is easier for getting the same code running locally and on the cloud (or another computer).
  19. @wronk wronk revised this gist Jan 2, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -25,7 +25,7 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    **Installation**:
    `pip install virtualenv`
    **Use:** It's possible to use virtualenv directly as ([as described here](https://virtualenv.pypa.io/en/stable/userguide/), but we'll use virtualenvwrapper instead.
    **Use:** It's possible to use virtualenv directly as ([as described here](https://virtualenv.pypa.io/en/stable/userguide/)), but we'll use virtualenvwrapper instead.
    **Technical details**: virtualenv keeps each environment (and its installed modules) in separate folders; therefore, each is like a silo that doesn't interact with any other virtual environment. Usually, the exact file location is defined by the user, but we can use virtualenvwrapper to instead handle this for us.
  20. @wronk wronk revised this gist Jan 2, 2018. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -24,6 +24,8 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    **Installation**:
    `pip install virtualenv`
    **Use:** It's possible to use virtualenv directly as ([as described here](https://virtualenv.pypa.io/en/stable/userguide/), but we'll use virtualenvwrapper instead.
    **Technical details**: virtualenv keeps each environment (and its installed modules) in separate folders; therefore, each is like a silo that doesn't interact with any other virtual environment. Usually, the exact file location is defined by the user, but we can use virtualenvwrapper to instead handle this for us.
    @@ -37,7 +39,7 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    ```
    Make sure that the directory you define for `WORKON_HOME` actually exists, and then either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    **Use** First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    **Use:** First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    ```
    pyenv global 3.6.3 # Set your system's python version with pyenv
    mkvirtualenv my_project_py3 # Create a new virtual environment using virtualenvwrapper; it'll be tied to Python 3.6.3
  21. @wronk wronk revised this gist Jan 2, 2018. 1 changed file with 15 additions and 2 deletions.
    17 changes: 15 additions & 2 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -52,7 +52,20 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    ```
    ## Other notes
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    1. Environment Prefix on source prompt
    If you want your command prompt to show the environment you're currently working with, add this to you .bashrc/.bash_profile:
    ```
    # Prefix source prompt with virtualenvwrapper environment
    if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
    eval "$(pyenv virtualenv-init -)"
    export PYENV_VIRTUALENVWRAPPER_PREFER_PYVENV="true"
    ```
    The command prompt will now look something like `(my_project_py3) Mark@Marks-MBP:~/Builds/ $`
    1. Directory scheme
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code. That tends to be easier for getting the same code running locally and on the cloud (or another computer).
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable instead of a hard-coded path, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code so it'll work on any machine that mirrors my directory scheme. That tends to be easier for getting the same code running locally and on the cloud (or another computer).
  22. @wronk wronk revised this gist Jan 2, 2018. 1 changed file with 10 additions and 4 deletions.
    14 changes: 10 additions & 4 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -27,11 +27,17 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    **Technical details**: virtualenv keeps each environment (and its installed modules) in separate folders; therefore, each is like a silo that doesn't interact with any other virtual environment. Usually, the exact file location is defined by the user, but we can use virtualenvwrapper to instead handle this for us.
    3. **virtualenvwrapper[https://virtualenvwrapper.readthedocs.io/en/latest/]**. This helps pyenv and virtualenv gel like PB&J. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    3. **[virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/)**. This helps pyenv and virtualenv gel like PB&J. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    **Installation**: `pip install virtualenvwrapper` and then follow some one-time [installation instructions](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction)
    **Use** First, we'll set the python environment and then make a couple virtual environments. Then you can use the `workon` command to switch between them.
    **Installation**: `pip install virtualenvwrapper` and then you'll need to do some one-time setup; in your .bashrc/.bash_profile, create the bash environment variable `WORKON_HOME` and source the virtualenv wrapper script:
    ```
    #virtualenv
    export WORKON_HOME=$HOME/.virtualenvs
    source /usr/local/bin/virtualenvwrapper.sh
    ```
    Make sure that the directory you define for `WORKON_HOME` actually exists, and then either restart your terminal or source the relevant configuration (i.e., `source ~/.bashrc` or `source ~/.bash_profile`). You can find the full [installation instructions here](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction).
    **Use** First, we'll set the python environment with pyenv, and then make a couple virtual environments with virtualenvwrapper. Then we'll use the `workon` command to switch between them.
    ```
    pyenv global 3.6.3 # Set your system's python version with pyenv
    mkvirtualenv my_project_py3 # Create a new virtual environment using virtualenvwrapper; it'll be tied to Python 3.6.3
  23. @wronk wronk revised this gist Jan 2, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,7 @@
    ## Overview
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different needs) on your default computer system. Concrete examples of this situation:

    ## Use cases
    ### Use cases
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2 project and a Python 3 project, or building a module that needs to work across multiple versions of python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    2. If you want to execute code on the cloud, you can set up a python environment that mirrors the relevant cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    3. You might have some working python code and want to make sure everything stays frozen so that it'll still work in the future. Without virtual environments, upgrading python modules could unintentionally break that year-old project. Having to go back and determine the correct version for each dependency would be a huge pain.
  24. @wronk wronk revised this gist Jan 2, 2018. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,3 +1,4 @@
    ## Overview
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different needs) on your default computer system. Concrete examples of this situation:

    ## Use cases
  25. @wronk wronk revised this gist Jan 2, 2018. 1 changed file with 20 additions and 16 deletions.
    36 changes: 20 additions & 16 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,16 +1,16 @@
    When you're working on multiple programming projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects with different needs on your default computer system.
    When you're working on multiple coding projects, you might want a couple different version of python and/or modules installed. That way you can keep each project in its own sandbox instead of trying to juggle multiple projects (each with different needs) on your default computer system. Concrete examples of this situation:

    ## Use cases
    1. Working on multiple projects that each have their own package dependencies; e.g., a Python 2 project and a Python 3 project, or two projects that use different versions of the same module. It's not reasonable to have to uninstall/reinstall modules every time you want to switch environments.
    2. If you want to execute code on the cloud, you can set up a python environment that mirrors the cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    1. Working on 2+ projects that each have their own dependencies; e.g., a Python 2 project and a Python 3 project, or building a module that needs to work across multiple versions of python. It's not reasonable to uninstall/reinstall modules every time you want to switch environments.
    2. If you want to execute code on the cloud, you can set up a python environment that mirrors the relevant cloud instance. For example, one of Amazon's main EC2 deep learning instances runs Python 3.4, and you may hit obstacles if you use code developed on your machine with Python 3.6.
    3. You might have some working python code and want to make sure everything stays frozen so that it'll still work in the future. Without virtual environments, upgrading python modules could unintentionally break that year-old project. Having to go back and determine the correct version for each dependency would be a huge pain.

    If some of your required libraries don't work with Anaconda, pyenv and virtualenv are one way to get a good balance of control without too much technical hassle. I'll list the tools, what they are, and how they fit together below.
    If some of your required libraries don't work with Anaconda, pyenv and virtualenv (along with virtualenvwrapper) are a good approach to gain lower-level control without too much technical complication. Note, however, that there are **a lot** more ways to make your workflow fancier and more efficient. This guide covers what pyenv, virtualenv, and virtualenvwrapper are, how they're installed/used, and how they fit together.

    ## Overview of the tools and setup
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "python environment." This manages which version of python is visible to your computer. With it, you can install multiple versions of python and quickly switch between the "activated" version. Here, we'll switch the version of python we're using with `workon` (as described later).
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "python environment." This manages which version of python is visible to your computer (and temporarily hides any others). With pyenv, you can install multiple versions of python and quickly switch between the "activated" version (i.e., the version your computer will use to execute code). Here, we'll switch the version of python we're using with virtualenvwrapper's `workon` command (as described later).

    **Installation/use**: `brew install pyenv` on Mac. See the docs for installation via Github clone on other other systems. Then you can install new python versions, list installed versions, and set the python environment like:
    **Installation/use**: `brew install pyenv` on Mac. See the docs for installation via `git clone` on other other systems. Then you can install new python versions, list installed versions, and set the python version like:
    ```
    pyenv install 3.6.3 # Install python version
    pyenv install 3.4.0
    @@ -19,29 +19,33 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    ```
    **Technical details**: Every time you execute a python script or use pip, pyenv works in the background to intercept that command and send it to the python environment that is currently activated. It does this using shims on the PATH environment variable, which allow python-related commands to be dynamically rerouted.
    2. **[virtualenv](https://virtualenv.pypa.io/en/stable/)**: Short for "virtual environment." This manages separate directories for the modules you install (e.g., with `pip`). That way, each virtual environment can have it's own set of installed modules, and that environment is walled off from every other virtual environment so they don't interfere with each other. Here, we'll also switch virtual environments with `workon` (as described later).
    2. **[virtualenv](https://virtualenv.pypa.io/en/stable/)**: Short for "virtual environment." This manages separate directories for the modules you install (e.g., with `pip`). That way, each virtual environment can have it's own set of installed modules that is walled off from every other virtual environment so they don't interfere with each other. Like with pyenv, we'll switch virtual environments with virtualenvwrapper's `workon` command (as described later).
    **Installation**:
    `pip install virtualenv`
    **Technical details**: virtualenv keeps each environment (and its installed modules) in a separate folder (XXX by default). Each is like a silo that doesn't interact with any other environment.
    **Technical details**: virtualenv keeps each environment (and its installed modules) in separate folders; therefore, each is like a silo that doesn't interact with any other virtual environment. Usually, the exact file location is defined by the user, but we can use virtualenvwrapper to instead handle this for us.
    3. **virtualenvwrapper[https://virtualenvwrapper.readthedocs.io/en/latest/]**. This helps pyenv and virtualenv work together like salt and pepper. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    3. **virtualenvwrapper[https://virtualenvwrapper.readthedocs.io/en/latest/]**. This helps pyenv and virtualenv gel like PB&J. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    **Installation**: `pip install virtualenvwrapper` and then follow some one-time [installation instructions](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction)
    **Use** First, we'll set the python environment and then make a couple virtual environments. Then you can use the `workon` command to switch between them.
    ```
    pyenv global 3.6.3 # Set your system's python version
    mkvirtualenv my_project_py3 # Create a new virtual environment; it'll be tied to Python 3.6.3
    pip install numpy scipy # Install the packages you need
    pyenv global 3.6.3 # Set your system's python version with pyenv
    mkvirtualenv my_project_py3 # Create a new virtual environment using virtualenvwrapper; it'll be tied to Python 3.6.3
    pip install numpy scipy # Install the packages you want in this environment
    pyenv global 2.7.0
    mkvirtualenv webdev_py2 # Create/switch to a new virtual environment; it'll be tied to Python 2.7.0
    pyenv global 2.7.0 # Set your system's python version with pyenv
    mkvirtualenv webdev_py2 # Create/switch to a new virtual environment; it'll use Python 2.7.0
    pip install flask boto
    workon # List the environments available
    workon my_project_py3 # Switch back to my_project_py3
    workon my_project_py3 # Use virtualenvwrapper to switch back to my_project_py3
    ```
    There are **a lot** of ways to make your workflow fancier and more efficient. This is a good starter if you want/need multiple environments and want to step beyond Anaconda.
    ## Other notes
    This is my own personal preference, but when setting up my python environment, I also tend to store modules I'm developing in a `Builds` directory (i.e., `/Users/wronk/Builds`). Similarly, I put data in `/Users/wronk/Data`. Then, I'll define an environment variable (e.g., `BUILDS_DIR` and `DATA_DIR`) so that writing scripts/python code is more agnostic of the exact machine I'm using.
    For example, any shell scripts can traverse directories from the `BUILDS_DIR` environment variable, and I'll use something like `my_data_dir = os.environ['DATA_DIR']` in python code. That tends to be easier for getting the same code running locally and on the cloud (or another computer).
  26. @wronk wronk revised this gist Dec 22, 2017. 1 changed file with 17 additions and 17 deletions.
    34 changes: 17 additions & 17 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -12,10 +12,10 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen

    **Installation/use**: `brew install pyenv` on Mac. See the docs for installation via Github clone on other other systems. Then you can install new python versions, list installed versions, and set the python environment like:
    ```
    `pyenv install 3.6.3` # Install python version
    `pyenv install 3.4.0`
    `pyenv versions` # List python versions
    `pyenv global 3.6.3` # Set your system's python version
    pyenv install 3.6.3 # Install python version
    pyenv install 3.4.0
    pyenv versions # List python versions
    pyenv global 3.6.3 # Set your system's python version
    ```
    **Technical details**: Every time you execute a python script or use pip, pyenv works in the background to intercept that command and send it to the python environment that is currently activated. It does this using shims on the PATH environment variable, which allow python-related commands to be dynamically rerouted.
    @@ -26,22 +26,22 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    **Technical details**: virtualenv keeps each environment (and its installed modules) in a separate folder (XXX by default). Each is like a silo that doesn't interact with any other environment.
    3. **virtualenvwrapper[https://virtualenvwrapper.readthedocs.io/en/latest/]**. This helps pyenv and virtualenv work together like salt and pepper. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle.Make sure pyenv and virtualenv are installed before you install this wrapper.
    3. **virtualenvwrapper[https://virtualenvwrapper.readthedocs.io/en/latest/]**. This helps pyenv and virtualenv work together like salt and pepper. With it, you can effectively switch between a single environment that has both the python version and virtual environment wrapped in one bundle. Make sure pyenv and virtualenv are installed before you install this wrapper.
    **Installation**: `pip install virtualenvwrapper` and then follow some one-time [installation instructions](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction)
    **Use** First, we'll set the python environment and then make a couple virtual environments. Then you can use the `workon` command to switch between them.
    ```
    `pyenv global 3.6.3` # Set your system's python version
    `mkvirtualenv my_project_py3` # Create a new virtual environment; it'll be tied to Python 3.6.3
    `pip install numpy scipy` # Install the packages you need

    `pyenv global 2.7.0`
    `mkvirtualenv webdev_py2` # Create/switch to a new virtual environment; it'll be tied to Python 2.7.0
    `pip install flask boto`

    `workon` # List the environments available
    `workon my_project_py3` # Switch back to my_project_py3
    ```
    ```
    pyenv global 3.6.3 # Set your system's python version
    mkvirtualenv my_project_py3 # Create a new virtual environment; it'll be tied to Python 3.6.3
    pip install numpy scipy # Install the packages you need
    pyenv global 2.7.0
    mkvirtualenv webdev_py2 # Create/switch to a new virtual environment; it'll be tied to Python 2.7.0
    pip install flask boto
    workon # List the environments available
    workon my_project_py3 # Switch back to my_project_py3
    ```
    There are **a lot** of ways to make your workflow fancier and more efficient. This is a good starter if you want/need multiple environments and want to step beyond Anaconda.
  27. @wronk wronk revised this gist Dec 22, 2017. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -31,7 +31,7 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    **Installation**: `pip install virtualenvwrapper` and then follow some one-time [installation instructions](https://virtualenvwrapper.readthedocs.io/en/latest/index.html#introduction)
    **Use** First, we'll set the python environment and then make a couple virtual environments. Then you can use the `workon` command to switch between them.
    ```
    `pyenv global 3.6.3` # Set your system's python version
    `mkvirtualenv my_project_py3` # Create a new virtual environment; it'll be tied to Python 3.6.3
    `pip install numpy scipy` # Install the packages you need
    @@ -42,6 +42,6 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen

    `workon` # List the environments available
    `workon my_project_py3` # Switch back to my_project_py3
    ```
    There are **a lot** of ways to make your workflow fancier and more efficient. This is a good starter if you want/need multiple environments and want to step beyond Anaconda.
  28. @wronk wronk revised this gist Dec 22, 2017. 1 changed file with 3 additions and 6 deletions.
    9 changes: 3 additions & 6 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -10,16 +10,13 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    ## Overview of the tools and setup
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "python environment." This manages which version of python is visible to your computer. With it, you can install multiple versions of python and quickly switch between the "activated" version. Here, we'll switch the version of python we're using with `workon` (as described later).

    **Installation/use**: `brew install pyenv` on Mac. See the docs for installation via Github clone on other other systems.
Then you can install new python versions, list installed versions, and set the python environment like:

    **Installation/use**: `brew install pyenv` on Mac. See the docs for installation via Github clone on other other systems. Then you can install new python versions, list installed versions, and set the python environment like:
    ```
    `pyenv install 3.6.3` # Install python version

    `pyenv install 3.4.0`

    `pyenv versions` # List python versions

    `pyenv global 3.6.3` # Set your system's python version

    ```
    **Technical details**: Every time you execute a python script or use pip, pyenv works in the background to intercept that command and send it to the python environment that is currently activated. It does this using shims on the PATH environment variable, which allow python-related commands to be dynamically rerouted.
    2. **[virtualenv](https://virtualenv.pypa.io/en/stable/)**: Short for "virtual environment." This manages separate directories for the modules you install (e.g., with `pip`). That way, each virtual environment can have it's own set of installed modules, and that environment is walled off from every other virtual environment so they don't interfere with each other. Here, we'll also switch virtual environments with `workon` (as described later).
  29. @wronk wronk revised this gist Dec 22, 2017. 1 changed file with 5 additions and 0 deletions.
    5 changes: 5 additions & 0 deletions python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -11,10 +11,15 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    1. **[pyenv](https://github.com/pyenv/pyenv)**: Short for "python environment." This manages which version of python is visible to your computer. With it, you can install multiple versions of python and quickly switch between the "activated" version. Here, we'll switch the version of python we're using with `workon` (as described later).

    **Installation/use**: `brew install pyenv` on Mac. See the docs for installation via Github clone on other other systems.
Then you can install new python versions, list installed versions, and set the python environment like:

    `pyenv install 3.6.3` # Install python version

    `pyenv install 3.4.0`

    `pyenv versions` # List python versions

    `pyenv global 3.6.3` # Set your system's python version

    **Technical details**: Every time you execute a python script or use pip, pyenv works in the background to intercept that command and send it to the python environment that is currently activated. It does this using shims on the PATH environment variable, which allow python-related commands to be dynamically rerouted.

    2. **[virtualenv](https://virtualenv.pypa.io/en/stable/)**: Short for "virtual environment." This manages separate directories for the modules you install (e.g., with `pip`). That way, each virtual environment can have it's own set of installed modules, and that environment is walled off from every other virtual environment so they don't interfere with each other. Here, we'll also switch virtual environments with `workon` (as described later).
  30. @wronk wronk revised this gist Dec 22, 2017. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion python_environment_setup.md
    View file
    Original file line number Diff line number Diff line change
    @@ -42,4 +42,4 @@ If some of your required libraries don't work with Anaconda, pyenv and virtualen
    `workon my_project_py3` # Switch back to my_project_py3


    There are **a lot** of ways to make your workflow fancier and more efficient. This is a good starter if you want/need multiple environments and want to step beyond Anaconda.
    There are **a lot** of ways to make your workflow fancier and more efficient. This is a good starter if you want/need multiple environments and want to step beyond Anaconda.