Hello, We have a few issues in tox that are essentially upstream bugs inside virtualenv. Hence, why I proposed myself to become a maintainer of virtualenv. I feel like tox is probably one of the bigger user bases out there. The first order of business would definitely be improving the CI and looking into how we can document all platform-specific edge cases we need to keep in mind inside the code base. One option of how to extend platform specific testing would probably be Docker images based on various distros. I'm not sure we can deprecate flags as that would break backward compatibility people may be relying on.
Bernat On Mon, Sep 17, 2018 at 10:31 AM 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. > 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/ >
-- 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/RG3Q6KH4AEZV6H52VEAH2AITBO7NQPYI/
