👍 Mostly because I had a tox -e venv which did 99.9% of this (it didn't print the executable version) and was removed at some point

In my workflow, I have TOXENV=python, so tox --notest creates a development environment (and also a test environment for the default python), thus avoiding the added complication of orchestrating these environments and leading to a pretty simple tox config. I'm okay with this project creating arbitrarily complex tox configuration, but I'll personally be using testenv for the latest stable Python for 99% of my workflows.

In my workflow, I have TOXENV=python, so tox --notest creates a development environment (and also a test environment for the default python)

I'm definitely in favor of simplifying things, but if I understand correctly, this only installs the [testenv]deps, and could also be accomplished with tox --devenv venv. I'd like one virtual environment with pytest, black, flake8, etc. This approach is also lightly documented by tox.

It's also relatively widespread in projects of any size and complexity (see also OpenStack and I believe Apache projects)

@gaborbernat If you're feeling generous with your time, I'm curious what you think of this, as a maintainer of virtualenv and tox.

Not sure what's the question, but I personally do prefer what this PR proposes. I've seen what @jaraco does, but I'd consider that a bit anti-pattern, though subjective at the end of the day, as it does not allow you to easily separate and recreate every python installation (could be just my experience, but version-specific bugs happen ever so often, and then it's good to quickly and easily reproduce them on your local machine).

Not sure what's the question, but I personally do prefer what this PR proposes

Thanks @gaborbernat; no specific question. I was just wondering what your overall impression was, for example if you had any suggestions for improvement or caveats to be aware of.