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. 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). 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. 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/
