On Fri., Sep. 7, 2018, 16:32 Dan Ryan, <dan@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: dan@danryan.co
From: Tzu-ping Chung [mailto:uranusjr@gmail.com <uranusjr@gmail.com>]
Sent: Friday, September 07, 2018 5:42 PM
To: Brett Cannon
Cc: Alex Becker; sorin.sbarnea@gmail.com; distutils-sig@python.org
Subject: [Distutils] Re: Adopting virtualenv package maintenance
On 08/9/2018, at 02:23, Brett Cannon <brett@python.org> wrote:
On Fri, 7 Sep 2018 at 11:18 Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Sep 7, 2018, 10:48 Brett Cannon <brett@python.org> wrote:
On Thu, 6 Sep 2018 at 13:44 Alex Becker <alcubecker@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-leave@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/M...