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. 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. -n
-- 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/M55DGNOU42R2TGV7CHB36NQKRHFGOXYR/
