Any way to move this along? It's just waiting a PR waiting to be merged. On Wednesday, November 29, 2017 at 9:45:44 AM UTC+1, Krzysztof Rosiński wrote: > > I thought I'd follow up on the discussion. The PR has been waiting for a > while, and it looks like a good step forward. Can a maintainer look into > it? There are a few reviews and approvals already. > > Thanks, > KR > > W dniu piątek, 29 września 2017 14:20:28 UTC+2 użytkownik > ssba...@redhat.com napisał: >> >> Well, as of today, Python activate scripts are much better than the >> virtualenv ones. >> >> My fix for Python was merged to master few minutes ago and it will also >> be backported to 3.6 branch. >> >> I guess that should be a good indication that we need to also fix the the >> issue in virtualenv. >> >> I think is time to review https://github.com/pypa/virtualenv/pull/1078 >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fpypa%2Fvirtualenv%2Fpull%2F1078&sa=D&sntz=1&usg=AFQjCNFWWG63jVy0voMOpyH0DaYc5nVv3Q> >> >> BTW, Look at the changes, I even fixed an obvious bug which was a missing >> "$" on one of the checks. Line >> https://github.com/pypa/virtualenv/pull/1078/files#diff-01d9e5f8d9d6bb4a6b8fd4a3db2e6557L58 >> >> --- I am wondering how did this went in as it was very easy to spot that >> the condition was not working as intended, always giving the same result. >> >> Regarding helping with PYPA projects, I would not mind giving some help >> here, especially on reviewing code on non-Windows platforms. >> >> On Thursday, September 28, 2017 at 3:05:54 PM UTC+1, Paul Moore wrote: >>> >>> I've seen your reports. Personally, I haven't responded because I'm a >>> Windows developer and I don't really have the knowledge of Unix to >>> reliably assess fixes like this. Normally, I'd be wiling to make some >>> level of common-sense judgement, but virtualenv is something of a >>> special case. Specifically: >>> >>> 1. The virtualenv test suite is very limited. We don't really test a >>> significant portion of the functionality, and in particular edge >>> cases, so the risk that any given PR has unintended consequences is >>> rather high. >>> 2. At its core, virtualenv is a set of pretty nasty hacks handling >>> special case behaviour for a variety of operating systems, Python >>> implementations, and customisations introduced by distribution vendors >>> into core Python. As a result, "it works on my system" is a >>> significantly worse predictor of quality than for other projects. >>> 3. Virtualenv is a core of many people's workflows, and any breakage >>> will have a significant effect. So we *have* to be conservative. >>> Conversely, the fact that a significant majority of the Python >>> community routinely use virtualenv without issue means that what >>> problems we *do* get reported probably aren't as widespread as the >>> poster believes (which is not to diminish the impact on that >>> individual). >>> >>> https://xkcd.com/1172/ is highly relevant here... >>> >>> Also, the PyPA team is 100% volunteers, and an extremely small team, >>> with a lot of much higher-profile work demanding our effort. So >>> regrettably, virtualenv is lower priority. >>> >>> With regard to the specifics of your issue, it's to do with the >>> activate script, which is a non-essential part of virtualenv. It's >>> completely possible to write your own activate script to replace it - >>> I know, because I have done precisely that. I didn't like the way the >>> supplied Windows activate scripts worked, so I wrote my own. Also, the >>> issue is when the script is used in bash with the non-standard strict >>> mode. That's not a common use case, and I, for one, don't know whether >>> every shell that is used by virtualenv users supports the "${PS1:-}" >>> syntax proposed in the fix (I know someone is going to claim "but it's >>> standard POSIX" - but we probably have users using other shells like >>> ksh, zsh, ancient Bourne shells on obsolete hardware, restricted >>> environments like boot loaders, ...). So while I could say "sure, it >>> looks simple, let's apply it" - who deals with the problems when the >>> change is released and we get a flood of Solaris users reporting >>> breakage with their shell? (This is of course an argument for complete >>> stagnation, and that's *not* my point - I'm just trying to emphasise >>> that we have to be careful and exercise judgement in ways that aren't >>> immediately obvious to someone on a mainstream system like Linux). >>> >>> So - after all those negative points, what *can* be done? >>> >>> 1. Improve the test suite. Patches that improve test coverage, work >>> out ways to test on non-standard hardware/shells/OSes (and no, I have >>> no idea how we'd do that via travis) would be fantastic. >>> 2. Improve the docs. Specifically by *reducing* users' expectations. >>> Docs explaining the role of the activate scripts, how they are >>> optional and don't do anything magical, and how to write your own >>> variation, would help people having difficulties with the standard >>> scripts. At its core, all virtualenv does is create a directory with a >>> copy of a python interpreter in it. Pretty much everything else is >>> optional (convenient, and essential for a usable user experience, but >>> replaceable). A better explanation of that might help people unhappy >>> with something delivered in the standard package (or it might not - >>> having to support their own customisations is not something everyone >>> has the time or resources to do). >>> 3. More difficult to do, but look beyond the "works for me" scope of a >>> PR. Test on multiple environments (and document what you've done in >>> the PR), ask for people to test on their environments, etc. A PR that >>> says "tested on (10 different systems, including some uncommon ones)" >>> is much more likely to be merged than one that says "works on my >>> Kubuntu 17.04 environment". >>> >>> Also, for Python 3, I'd strongly recommend looking at the core venv >>> module for virtual environment management. Its approach is supported >>> by the core interpreter code, so it's much more robust than >>> virtualenv, and it's probably the long-term solution to virtual >>> environment creation. Having said that, I doubt their activate scripts >>> are any better than ours ;-) >>> >>> Paul >>> >>> >>> On 28 September 2017 at 13:15, <ssba...@redhat.com> wrote: >>> > After spending a lot of effort trying to fix a bug in virtualenv I was >>> > hinted by a friend that I should also try the user mailinglist instead >>> of >>> > the development one. Well, I hope this would work even if it is clear >>> that >>> > reviewing and merging a patch is a development issue. >>> > >>> > The bug is documented at >>> https://github.com/pypa/virtualenv/issues/1029 and >>> > I have two patches for it one that solves it and one that assures that >>> there >>> > is no regression (details on bug on why this needs to go separate). >>> > >>> > The second problem is lack of feedback which is came as a big surprise >>> for >>> > me as I am usually impressed by how quickly other Python projects >>> > maintainers are reacting. >>> > >>> > - got zero feedback on both IRC channels #pypa and #pypa-dev >>> > - no replies on official pypa-dev mailing list even after 7 days - >>> > https://groups.google.com/forum/#!topic/pypa-dev/8iVHDOqsj9M >>> > - found a worrying report regarding a Trojan reported yesterday, this >>> one >>> > with no reply too. -- >>> > https://groups.google.com/forum/#!topic/pypa-dev/4Bsh6EN0Wm4 -- i >>> only hope >>> > that didn't appear from the distro itself. >>> > >>> > Does virtualenv needs some extra maintainer workforce? >>> > >>> > Thanks >>> > Sorin >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "virtualenv" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to python-virtual...@googlegroups.com. >>> > To post to this group, send email to python-v...@googlegroups.com. >>> > Visit this group at https://groups.google.com/group/python-virtualenv. >>> >>> > For more options, visit https://groups.google.com/d/optout. >>> >>
-- You received this message because you are subscribed to the Google Groups "virtualenv" group. To unsubscribe from this group and stop receiving emails from it, send an email to python-virtualenv+unsubscr...@googlegroups.com. To post to this group, send email to python-virtualenv@googlegroups.com. Visit this group at https://groups.google.com/group/python-virtualenv. For more options, visit https://groups.google.com/d/optout.
