The virtualenv package has more features than venv, but most of them aren't useful for us (though investigation is needed to see if it is indeed faster).

Additionally, it has the cost of being vendored in-tree: it takes up space, and we need to re-vendor whenever we want to use a newer version of pip/setuptools/wheel.

Instead, we should do python3 -m venv, then pip install pip==$pip_version wheel==$wheel_version setuptools==$setuptools_version.

Note: one caveat from venv is that on some distros, it's a separate package, so that would be one more thing people would need to ensure they have before they can run anything, and that could end up being annoying to track.

Was chewing on this a bit and wanted to dump some thoughts:

1. We shouldn't need to seed pip and friends after this patch vendoring them lands.
2. python3 -m venv --without pip <target> takes less than half the time of virtualenv <target> --no-seed, and that isn't considering the fact that we will be able to create the venv without starting a new Python process.
3. As raised over in this bug, MozillaBuild has a bug with the venv module, but that bug is worked around when --without-pip is used, which is perfect.
4. It'll be nice to remove the virtualenv package from the tree:
   • Re-vendoring it is manual and annoying.
   • It takes up ~10MB in-tree, removing it will slightly improve checkout and indexing times.
   • We no longer have to maintain our wrapping script and associated workflow documentation.

These aren't huge wins, but I think the pieces are falling such that this will be an easy improvement to tackle.

Blocking on 1732946 because pip & friends are vendored as part of that bug.

pip & friends are now vendored. The ticket itself isn't resolved, so I'm going to remove the "blocking" relationship.
One other note as part of this ticket: virtualenv provides an activate_this.py script, but venv does not. We'll need to replicate it in our own code as part of this ticket.

This was implemented in bug 1766497.