Thanks for pointing out the PR, I didn’t know that exists :D I made a thin wrapper around virtualenv/venv a while ago too. My intention is to use it to abstract away library differences so I can bring native venv support to Pipenv more easily, so the library has some special quirks (e.g. uses virtualenv on Python 3.3, even though venv is technically available) to suit its needs, but the idea is similar—create with venv if the Python installation supports it, otherwise fallback virtualenv. Just throwing it out here in case anyone is interested.
> On 16/9/2018, at 22:06, Nick Coghlan <ncogh...@gmail.com> wrote: > > On Sat, 8 Sep 2018 at 13:34, Brett Cannon <br...@python.org > <mailto:br...@python.org>> wrote: > On Fri., Sep. 7, 2018, 16:32 Dan Ryan, <d...@danryan.co > <mailto:d...@danryan.co>> wrote: > I’m thinking (and correct me if I’m wrong here) that Brett’s message might be > motivated more by a desire to standardize and centralize effort by first > assessing what the issue is. > > Yep. I try to take the decade view of things so solving stuff that will take > a while to trickle out to the community doesn't phase me. 😉 > > > Note that Donald created a draft virtualenv rewrite that worked as a thin > shell around venv on the versions that provided venv, but otherwise worked in > much the same as it always had: https://github.com/pypa/virtualenv/pull/697 > <https://github.com/pypa/virtualenv/pull/697> > > Around this time last year, he noted that he wasn't sure when he would be > able to find the time to follow up on it, and if someone else wanted to > pursue a different strategy he'd be OK with that: > https://github.com/pypa/virtualenv/pull/697#issuecomment-333937166 > <https://github.com/pypa/virtualenv/pull/697#issuecomment-333937166> > > So if folks are still interested in the general idea of improving virtualenv > and venv interoperability, then my last message to that thread and Paul's > follow up would be a decent place to start: > https://github.com/pypa/virtualenv/pull/697#issuecomment-333437537 > <https://github.com/pypa/virtualenv/pull/697#issuecomment-333437537> > > However, eliminating virtualenv as a project/component is a definite > *non*-goal. While venv is valuable because it integrates more tightly into > the interpreter startup sequence than virtualenv itself was ever able to (and > provides a common API for doing virtualenv-like things across different > Python implementations), virtualenv remains valuable as a cross-version > compatibility and enhancement layer for the parts that don't need to be as > tightly integrated with the core interpreter implementation. We just hope to > eventually be able to delete most of the code from it, and have it just > handle the parts that venv itself doesn't cover in any given version of > Python :) > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com <mailto:ncogh...@gmail.com> | > Brisbane, Australia > -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/RXBKWLQOMS2OM56VIVRZ6O3ALYZTRKHT/
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/THSTP27OFOHVZIAAXMHJ64XW2EE4M5UE/
