title: Python and virtualenv - why is the python version used to name subdirectories?
body: <p>Why does the virtualenv creation mechanism insist on naming subdirectories with the version of Python used?  I am referring to something like <code>test_venv/venv3/lib/&gt;&gt;&gt;python3.6&lt;&lt;&lt;/site-packages</code></p>
  
  <p>When you're in a 3.6 venv, you of course get 3.6 packages.  And same with 2.7 meaning 2.7 packages.  And you can't use these without <code>activate</code>-ing the venv beforehand so the risk of confusion seems low.</p>
  
  <p>Among other things people often have questions about why something is not working that have to do with either the OS system path or the python sys.path.  And having those subpaths named after the python version makes it hard to generalize on where to find <code>site-packages</code>.</p>
  
  <p>edit:  the following is on macOS, but I got roughly the same behavior on an Ubuntu 18.04 VM.</p>
  
  <h3>create a python 2 virtual environment with  <code>virtualenv ./venv2</code></h3>
  
  <p>directory structure with <code>tree -d -L 3 ./venv2/</code>:</p>
  
  <pre><code>./venv2/
  ├── bin
  ├── include
  │   └── python2.7 -&gt; /opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
  └── lib
      └── python2.7
          ├── config -&gt; /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config
          ├── distutils
          ├── encodings -&gt; /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/encodings
          ├── lib-dynload -&gt; /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
          └── site-packages
  </code></pre>
  
  <h3>create a python 3 virtual environment with  <code>python3 -m venv ./venv3</code></h3>
  
  <p>Slightly better, but still impacts site-packages.</p>
  
  <pre><code>./venv3/
  ├── bin
  ├── include
  └── lib
      └── python3.6
          └── site-packages
  </code></pre>