Sorry, hit the send button too soon. Here’s the project: https://github.com/sarugaku/virtenv <https://github.com/sarugaku/virtenv>
> On 16/9/2018, at 22:50, Tzu-ping Chung <uranu...@gmail.com> wrote: > > 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 >> <mailto: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 >> <mailto:distutils-sig@python.org> >> To unsubscribe send an email to distutils-sig-le...@python.org >> <mailto:distutils-sig-le...@python.org> >> https://mail.python.org/mm3/mailman3/lists/distutils-sig.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/IKRNSK7QUSTFCB2576EUVNWTVLB2U7ET/