On Monday, September 17, 2018, Paul Moore <p.f.mo...@gmail.com> wrote:
> On Sun, 16 Sep 2018 at 15:08, Nick Coghlan <ncogh...@gmail.com> wrote: > > > So if folks are still interested in the general idea of improving > virtualenv and venv interoperability, then my last message to that thread > and Paul's follow up would be a decent place to start: > https://github.com/pypa/virtualenv/pull/697#issuecomment-333437537 > > > > However, eliminating virtualenv as a project/component is a definite > *non*-goal. While venv is valuable because it integrates more tightly into > the interpreter startup sequence than virtualenv itself was ever able to > (and provides a common API for doing virtualenv-like things across > different Python implementations), virtualenv remains valuable as a > cross-version compatibility and enhancement layer for the parts that don't > need to be as tightly integrated with the core interpreter implementation. > We just hope to eventually be able to delete most of the code from it, and > have it just handle the parts that venv itself doesn't cover in any given > version of Python :) > > +1 on this. > > I'd also consider the possibility of taking the core virtualenv code > used to build a virtual environment on Python 2.7 (and Python 3 > versions without venv, if you insist) and using it to support the same > programming API that venv provides. Writing front ends against the > venv API alone would be a nice simplification, and would clearly > isolate the bits of virtualenv that are the "essential core" from the > UI/frontend parts. I don't know how easy that would be to do, but it's > probably worth looking at. > > In my view, the best long-term approach to making virtualenv > sustainable is along those lines - where possible, use the core venv > for the low-level "make a virtual environment" functionality, and use > the existing virtualenv approach (which is basically a series of > hacks) to support systems where venv isn't an option. Then on top of > that, have a common UI (which would probably be essentially the same > as the current virtualenv UI, at least in the short term). Even if > that's ultimately going to be the "new virtualenv" (option 1 from > Nick's comment referenced above) it can be prototyped as a standalone > utility (Tzu-ping Chung's wrapper is something along those lines, but > to be a "proper" prototype of the way forward it would need to include > the relevant virtualenv code, rather than calling out to virtualenv). > > As far as maintainability of virtualenv itself goes, I'm very > reluctant to get sucked into debates here - last time I tried to > discuss the issues behind why virtualenv is so hard to maintain, I was > subjected to some *very* hostile responses, and I'm not willing to > deal with anything like that again. But for what it's worth, and I > don't intend to do anything more than state the following and leave it > at that, my views are as follows: > > 1. Virtualenv is extremely widely used, and so has to be very cautious > about backward compatibility. The code is full of special cases for > various systems (particularly the many Unix variants around) and we > don't have any sort of testing to ensure that we don't break things. > Any PR that comes in affecting the core functionality is (entirely > understandably) focused on fixing an issue with the submitter's > environment. But who will make sure that it doesn't break some other > environment? And how will they do that? Having a formal statement of > what systems we support would limit the risks here, but wouldn't > fundamentally alter the problem. It would mostly just let us reject a > higher proportion of issue reports and PRs, which isn't really > helpful. Tests would be helpful, indeed. Which {Linux, OSX, Windows, Unix*} {Bash, ZSH, Fish, } {CPython, PyPy, Jython, IronPython} shells have issues? Are there GitHub issue labels for each of these features of the build matrix? > 2. There are a lot of rarely if ever used options to virtualenv, some > of which are known to be at least partially broken (--clear, --prompt, > --relocatable). --relocatable only doesn't work when necessarily absolute paths are hardcoded in checksummed fixed-width fields in binaries, AFAIR. I can't even remember what --clear or --prompt do, OTOH. > Rather than try to fix or support these, we should > simply remove them. Again, it's about reducing the support burden of > having to investigate issues in functionality that we aren't confident > in, and have no experience with. > 3. We should clearly separate the various aspects of virtualenv: > a) The core functionality of making a "virtual environment". This > is the most vital part of virtualenv and the most fragile. But it's > also the bit that mostly "just works". (If it didn't, everyone using > tox would be screaming, for a start). > b) The support features - activate scripts, in particular. These > are in theory completely optional, although it would be naive to > ignore the fact that "activate" is most people's normal interaction > with virtualenv. IMO, the activate scripts should take a "lowest > common denominator" approach, and we should push back on requests to > load functionality onto them. There's a particular complication here > in that we should provide the same behaviour from all the activate > scripts (e.g., setting a $VIRTUAL_ENV environment variable) and > finding someone who can maintain that feature parity across 3 > different Unix shells and 2 Windows shells is pretty difficult, so any > changes risk introducing discrepancies. > c) The UI, which includes the command line interface and the API for > extending virtualenv > (https://virtualenv.pypa.io/en/stable/reference/#creating- > your-own-bootstrap-scripts > - which I suspect no-one ever uses). This is relatively easy to > support, but I don't recall the last time I saw an issue in this area. > 4. We have essentially no test suite, and no CI to run one (even if we > did have one) on anything more than a tiny fraction of the > environments we support (e.g. Travis is Ubuntu only - so won't cover > things like the Gentoo specific code). So we've no way of catching > regressions. Travis has Linux and OSX/MacOS CI environments (w/ Homebrew). https://docs.travis-ci.com/user/multi-os/ https://docs.travis-ci.com/user/reference/osx/ Appveyor has Linux and Windows ci environments. Appveyor is also used by conda-forge (conda-smithy) for Windows CI environments. https://www.appveyor.com/docs/build-environment/ conda-smithy adds a push hook to run CI builds on all supported CI platforms on git push: https://github.com/conda-forge/conda-smithy > 5. As noted above, we've never to my knowledge had bug reports from > people using virtualenv via tox (or, nox, pew, or any of the other > projects that use virtualenv to support their functionality). And I > believe that those constitute the *vast* majority of virtualenv users. > We have to prioritise not breaking those uses above anything else (I > don't want to be the person responsible for causing every Python CI > run on Travis to go red... :-)) > > Maybe we should drop support for everything but the most common > platforms. That would certainly help sustainability, IMO. But who > decides what's supported? Do we drop Gentoo? What about the fish > shell? Or Jython or PyPy? What about Python 3.1? Don't ask me, unless > you want an answer something like "CPython 2.7 and 3.4+, on Windows 7+ > or Mac OS, Ubuntu and Fedora versions less than 2 years old, non-root > users, default config only, and only bash, Powershell and CMD". And > I'm being generous even going that far... > > Just some thoughts to consider before diving into major upheavals with > virtualenv. > > Paul > -- > 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/ > TEFZLIWXIQ4OAQ3FUT7WB6RXTAJUR2FJ/ >
-- 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/JEEPRVUWQX7LDEL3PSY34RGZCH5J6GIO/
