Re: Adopting virtualenv package maintenance

On Fri., Sep. 7, 2018, 16:32 Dan Ryan, <[email protected]> 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: [email protected]
>
> From: Tzu-ping Chung [mailto:[email protected] <[email protected]>]
>
> Sent: Friday, September 07, 2018 5:42 PM
>
> To: Brett Cannon
>
> Cc: Alex Becker; [email protected]; [email protected]
>
> Subject: [Distutils] 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]> wrote:
>
> On Fri, Sep 7, 2018, 10:48 Brett Cannon <[email protected]> wrote:
>
> On Thu, 6 Sep 2018 at 13:44 Alex Becker <[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
>
> 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 -- [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/ZIRLQFNO6CRJMAYTC2EVFGEWYWIWZQKS/