I'm guessing this would look something like:

• Vendored package requirements would be placed in virtualenv requirements files (<venv>_virtualenv_packages.txt)
• When vendoring, all virtualenv requirements files will be read, and a version of each vendored package that satisfies all requirements will be vendored
• A requirements.txt file will still be generated in third_party/python/requirements.txt
• The sys.path modifications required will be automatically generated for the vendored requirement and its dependencies.

Why?
Three reasons:

1. Right now, it's hard to keep track of where to specify a dependency ("do I put it in a virtualenv requirement file, or in third_party/python/requirements.in?")
2. Don't forget to add the vendored package's path to <venv>_virtualenv_packages.txt!
3. As of bug 1730712, system packages are more-frequently in-scope. However, they aren't currently asserted to be the same version as the in-tree variants.