> 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 > <mailto:n...@pobox.com>> wrote: > On Fri, Sep 7, 2018, 10:48 Brett Cannon <br...@python.org > <mailto:br...@python.org>> wrote: > > > On Thu, 6 Sep 2018 at 13:44 Alex Becker <alcubec...@gmail.com > <mailto: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 <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 <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/NEC322PDDNIWDYHJNLESZQQ5WWGSNEAC/
