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. 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)
- Inability of venv to accurately determine the real python prefix when invoked
inside another virtual environment
(https://github.com/pypa/virtualenv/issues/1095,
https://bugs.python.org/issue30811)
- pipenv is often called inside a virtualenv to create a new virtualenv
- 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
Dan Ryan
gh: @techalchemy // e: d...@danryan.co
From: Tzu-ping Chung [mailto:uranu...@gmail.com]
Sent: Friday, September 07, 2018 5:42 PM
To: Brett Cannon
Cc: Alex Becker; sorin.sbar...@gmail.com; distutils-sig@python.org
Subject: [Distutils] Re: Adopting virtualenv package maintenance
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> wrote:
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.
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-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/SIKOLHAXJPTXJDR6VJCKD523PXB3FQ43/
