On Fri., Sep. 7, 2018, 16:32 Dan Ryan, <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. 😉 The way I see it, we have a few major issues in play and a bunch of options > > - Python 2 support (venv is python 3 only and we are supporting python 2 > over in pipenv for the next year and a half at least) > > - Would mean additional logic and complexity and support for both > virtualenv > and venv anywhere we need to use a virtualenv (whereas virtualenv just > supports both to begin with) > > - Added complexity, higher maintenance cost, some benefit to > users but high probability of new bugs in our code at least > > - activate_this.py (which provides critical inline activation for us when > people invoke "pipenv run" from the command line) > It might make sense to try and add an 'activate' command to venv, e.g. 'python -m venv --activate .venv' as a UX convenience. - Inability of venv to accurately determine the real python prefix when > invoked inside another virtual environment ( > *https://github.com/pypa/virtualenv/issues/1095* > <https://github.com/pypa/virtualenv/issues/1095>, > *https://bugs.python.org/issue30811* <https://bugs.python.org/issue30811>) > > - pipenv is often called inside a virtualenv to create a new > virtualenv > I assume that could be fixed somehow (and people installing pipenv in a virtual environment to then create another environment using that newly installed pipenv helps explain why people do that nesting 😄). - virtualenv is the primary container on CI/build systems like > travis > > - Someone mentioned an issue with pip installation on one of the trackers > I follow, but I’m not clear on the details there and I couldn’t find > anything relevant quickly > > IMO it makes total sense to focus core development on venv, with a > compatibility library (i.e. virtualenv?) to extend functionality through > 2020. I know there was some talk of reworking virtualenv but Donald has > been focused on warehouse and I’m not sure when that will change. Having > dedicated maintainership of someone who could provide compatibility shims > on top of venv with injection of activate_this.py and some functionality > to handle the prefix issues would be a big help, but I’m not sure how > many of the open PRs will actually accomplish that. > > Perhaps if venv had all of these things, we could just publish a backport > for it and that would provide a transition path > I don't think that would work as venv, if I remember correctly, utilizes changes made to the interpreter to have a better integration. -Brett Dan Ryan > > gh: @techalchemy // e: d...@danryan.co > > From: Tzu-ping Chung [mailto:uranu...@gmail.com <uranu...@gmail.com>] > > Sent: Friday, September 07, 2018 5:42 PM > > To: Brett Cannon > > Cc: Alex Becker; sorin.sbar...@gmail.com; distutils-sig@python.org > > Subject: [Distutils] Re: Adopting virtualenv package maintenance > > On 08/9/2018, at 02:23, Brett Cannon <br...@python.org> wrote: > > On Fri, 7 Sep 2018 at 11:18 Nathaniel Smith <n...@pobox.com> wrote: > > On Fri, Sep 7, 2018, 10:48 Brett Cannon <br...@python.org> wrote: > > On Thu, 6 Sep 2018 at 13:44 Alex Becker <alcubec...@gmail.com> wrote: > > Another +1 to the utility of a maintainer. I am also working on package > management and have found that venv is not a full replacement for > virtualenv--for example I don't believe the environment can be entered > programatically, while virtualenv provides activate_this.py which can be > exec'd. I'm sure there are many other limitations, so I don't think python > can give up on virtualenv soon. > > But are those inherent limitations of venv or simply a lack of a provided > API or library to have the equivalent abilities? I assume there's a > difference between keeping virtualenv running versus developing a small > library on top of venv to backfill some things. > > I guess venv being in the stdlib means that any limitations it has are > going to keep limiting "python -m venv" for quite a while. > > Depends on the type of limitation. Alex mentioned an activate_this.py > script that makes activation a generic thing. That doesn't strike me as > something that requires changes in the stdlib and instead something on PyPI > that provided the equivalent for venv (and potentially also being in the > stdlib). > > Just want to mention that adding activate_this.py to venv has been > proposed, and rejected. > > https://bugs.python.org/issue21496 > > Also there is an interpolation problem when you want to create a venv out > of a virtualenv. > > https://bugs.python.org/issue30811 > > While I agree with Vinay that this isn’t really a venv problem, it does > still require a solution > > in some way. If venv doesn’t change, virtualenv needs to. > > No matter what the future of virtualenv is (rewritten on top of venv or > not), I think it is at > > least reasonable to say that virtualenv needs *some* work, and someone > needs to work on > > it? Because virtualenv is still being used at a very high volume while we > are exchanging words, > > and there are a lot of simple improvements people can benefit from right > now. > > > > > If we want to work around these limits on something other than the Python > release cycle, then it means training users to not run "python -m venv", > and instead run "python -m somethingelse". > > > > So long as that's necessary, the "somethingelse" might as well be > "virtualenv", which is what everyone is already trained to do anyway... > > There have been plans at various points to rewrite virtualenv on top of > venv, and as far as I know the limiting factor was time/energy, not that > they hit some intrinsic limitation. > > As is everything in open source. ;) I'm just trying to understand if > there's something that specifically needs to change in venv long-term or > not. > > -- > > 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/MIF3VTCHQIKRNS2UJEGTSBTW2SMCWTT4/ > >
-- 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/ZIRLQFNO6CRJMAYTC2EVFGEWYWIWZQKS/
