virtualenv: Scripts and bin in bad location

Reporting the same bug here on MacOS, only I’m highlighting the old vs new-unexpected behavior in a (hopefully) easy reproduction case:

./.test-venv/bin/pip list | grep virtualenv
virtualenv         16.7.9
./.test-venv/bin/python -m virtualenv .mac-os-venv
Using base prefix '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7'
New python executable in /Users/aegelhofer/.mac-os-venv/bin/python
Installing setuptools, pip, wheel...
done.
ls ~/.mac-os-venv/bin/*
/Users/aegelhofer/.mac-os-venv/bin/activate		/Users/aegelhofer/.mac-os-venv/bin/pip
/Users/aegelhofer/.mac-os-venv/bin/activate.csh		/Users/aegelhofer/.mac-os-venv/bin/pip3
/Users/aegelhofer/.mac-os-venv/bin/activate.fish	/Users/aegelhofer/.mac-os-venv/bin/pip3.7
/Users/aegelhofer/.mac-os-venv/bin/activate.ps1		/Users/aegelhofer/.mac-os-venv/bin/python
/Users/aegelhofer/.mac-os-venv/bin/activate.xsh		/Users/aegelhofer/.mac-os-venv/bin/python-config
/Users/aegelhofer/.mac-os-venv/bin/activate_this.py	/Users/aegelhofer/.mac-os-venv/bin/python3
/Users/aegelhofer/.mac-os-venv/bin/easy_install		/Users/aegelhofer/.mac-os-venv/bin/python3.7
/Users/aegelhofer/.mac-os-venv/bin/easy_install-3.7	/Users/aegelhofer/.mac-os-venv/bin/wheel
rm -rf .mac-os-venv
./.test-venv/bin/pip install -U virtualenv
Looking in indexes:
 ...
Requirement already satisfied, skipping upgrade: six<2,>=1.9.0 in ./.test-venv/lib/python3.7/site-packages (from virtualenv) (1.14.0)
Requirement already satisfied, skipping upgrade: importlib-metadata<2,>=0.12; python_version < "3.8" in ./.test-venv/lib/python3.7/site-packages (from virtualenv) (1.5.0)
Requirement already satisfied, skipping upgrade: filelock<4,>=3.0.0 in ./.test-venv/lib/python3.7/site-packages (from virtualenv) (3.0.12)
Requirement already satisfied, skipping upgrade: appdirs<2,>=1.4.3 in ./.test-venv/lib/python3.7/site-packages (from virtualenv) (1.4.3)
Requirement already satisfied, skipping upgrade: distlib<1,>=0.3.0 in ./.test-venv/lib/python3.7/site-packages (from virtualenv) (0.3.0)
Requirement already satisfied, skipping upgrade: zipp>=0.5 in ./.test-venv/lib/python3.7/site-packages (from importlib-metadata<2,>=0.12; python_version < "3.8"->virtualenv) (2.2.0)
Installing collected packages: virtualenv
  Found existing installation: virtualenv 16.7.9
    Uninstalling virtualenv-16.7.9:
      Successfully uninstalled virtualenv-16.7.9
Successfully installed virtualenv-20.0.4
./.test-venv/bin/python -m virtualenv .mac-os-venv
created virtual environment in 169ms CPython3Posix(dest=/Users/aegelhofer/.mac-os-venv, clear=False, global=False) with seeder FromAppData pip=latest setuptools=latest wheel=latest app_data_dir=/Users/aegelhofer/Library/Application Support/virtualenv/seed-v1 via=copy

Now at this point I expect the python and pip “binaries” to be under ~/.mac-os-venv/bin/*, but they now seem to be under ~/.mac-os-venv/<sourced-prefix>/bin/*:

ls ~/.mac-os-venv/bin/*
zsh: no matches found: /Users/aegelhofer/.mac-os-venv/bin/*
ls ~/.mac-os-venv/usr/local/bin/*
/Users/aegelhofer/.mac-os-venv/usr/local/bin/activate		/Users/aegelhofer/.mac-os-venv/usr/local/bin/pip
/Users/aegelhofer/.mac-os-venv/usr/local/bin/activate.csh	/Users/aegelhofer/.mac-os-venv/usr/local/bin/pip-3.7
/Users/aegelhofer/.mac-os-venv/usr/local/bin/activate.fish	/Users/aegelhofer/.mac-os-venv/usr/local/bin/pip3
/Users/aegelhofer/.mac-os-venv/usr/local/bin/activate.ps1	/Users/aegelhofer/.mac-os-venv/usr/local/bin/python
/Users/aegelhofer/.mac-os-venv/usr/local/bin/activate.xsh	/Users/aegelhofer/.mac-os-venv/usr/local/bin/python3
/Users/aegelhofer/.mac-os-venv/usr/local/bin/activate_this.py	/Users/aegelhofer/.mac-os-venv/usr/local/bin/python3.7
/Users/aegelhofer/.mac-os-venv/usr/local/bin/easy_install	/Users/aegelhofer/.mac-os-venv/usr/local/bin/wheel
/Users/aegelhofer/.mac-os-venv/usr/local/bin/easy_install-3.7	/Users/aegelhofer/.mac-os-venv/usr/local/bin/wheel-3.7
/Users/aegelhofer/.mac-os-venv/usr/local/bin/easy_install3	/Users/aegelhofer/.mac-os-venv/usr/local/bin/wheel3

This behavior change messes with tools like tox that expect to have the pip binary under <ENV-ROOT>/bin - Reading the changelog I didn’t see anything mentioning this behavior change

If this is un-related, I can file a separate bug, but it seems suspect that we’re getting hung up on the same issues relating to “prefixes” here. Attached is my debug output of virtualenv-20.0.4 command creating a virtualenv:

virtualenv-debug-output-issue-1632.txt

_Originally posted by @andrewegel in https://github.com/pypa/virtualenv/issues/1632#issuecomment-586485362_

PS. moved here as it’s a new issue.