Re: Adopting virtualenv package maintenance

> On 08/9/2018, at 02:23, Brett Cannon <[email protected]> wrote:
> 
> 
> 
> On Fri, 7 Sep 2018 at 11:18 Nathaniel Smith <[email protected] <mailto:[email protected]>> wrote:
> On Fri, Sep 7, 2018, 10:48 Brett Cannon <[email protected] <mailto:[email protected]>> wrote:
> 
> 
> On Thu, 6 Sep 2018 at 13:44 Alex Becker <[email protected] <mailto:[email protected]>> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/MIF3VTCHQIKRNS2UJEGTSBTW2SMCWTT4/

--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/NEC322PDDNIWDYHJNLESZQQ5WWGSNEAC/