Reviewing https://twine.readthedocs.io/en/latest/contributing.html , @alanbato asked whether we should start recommending Pipenv for isolating the dev environment of the project, since (if he understands correctly) it is sponsored by the PyPA as the recommended tool for new projects.
I believe, and I could be wrong, that the Pipenv is more focused on application development rather than development of a thing that has to work across multiple versions. As a result, we need tox or something that behaves like tox. If Pipenv replaces tox, let's document it and move to it, otherwise, I don't see how we can use Pipenv.
If I'm not mistaken, what tox does is use pip and virtualenv programatically to create tests environments with different versions to test one.
In theory, one could replace those pip+virtualenv calls within tox with pipenv and work the same way. See related issue
In practice, apparently a solution like this already exists as tox-pipenv. But I'm not sure how production-ready it is and how easily would it replace tox. Some auditing and testing needs to be done but it's totally doable.
However, I understand that virtualenv is more stable and is used by both Pipenv and Tox internally, and it works just fine as it is.
Just wondering if we should eat our own dogfood :dog: in this case or not :)
If it were my dogfood, I'd definitely eat it. In reality, doesn't pipenv also rely on pip and virtualenv? So we're just adding an abstraction layer? Tox manages both for us, but now we want tox to manage pipenv to manage those for us? That seems a little odd.
Re "pipenv is for apps": https://docs.pipenv.org/advanced/#pipfile-vs-setup-py
Thanks for the discussion and explanations, all. I'm comfortable staying with our current virtual environment and test management recommendations.
If, at some point at least 4 months from now, the situation around pipenv, virtualenv, and tox has shifted enough for us to consider changing, please open a new issue and refer to this one. Thanks!
Most helpful comment
I believe, and I could be wrong, that the Pipenv is more focused on application development rather than development of a thing that has to work across multiple versions. As a result, we need tox or something that behaves like tox. If Pipenv replaces tox, let's document it and move to it, otherwise, I don't see how we can use Pipenv.