> On Jul 13, 2019, at 3:44 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > > > > >> On Fri, Jul 12, 2019 at 11:22 PM Jonathan Bedard <jbed...@apple.com> wrote: >> I would agree that if we move to Python 3, we need a script which installs >> Python 3 in an impossible to mess-up way on Mojave and High Sierra. >> >> I don’t think the clang comparison is fair here. Python 2 is officially >> deprecated in 2020, we can’t expect security updates to the language or any >> libraries we depend on 6 months from now. It’s not really a question of if >> we stop supporting Python 2, but rather, when we stop supporting Python 2. > > I don’t think anyone is arguing that we’d eventually need to move to Python3. > I’m arguing that it’s not okay to require random WebKit contributor to know > some obscure python insanity to install Python 3, or have a script that > installs Python 3 and breaks all other python scripts in the system. > >> >> It’s also worth noting that in Catalina, we will need some script to install >> XCode Command Line Tools since SVN, Python 2.7 and Python 3 are no longer >> included by default in the new Xcode. Given this, it doesn’t seem terrible >> if the script responsible for installing XCode CL tools also installs Python >> 3 for older Mac versions. > > Yes, as long as it doesn’t replace or break existing Python2.7 and/or other > python scripts in the system.
This is exactly what virtualenvs can do. And this is how we should do it IMO, even for systems that natively have some version of Python 3. > >> >>>> On Jul 12, 2019, at 7:34 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >>>> >>> >> >>> >>>> On Fri, Jul 12, 2019 at 7:03 PM Michael Catanzaro <mcatanz...@igalia.com> >>>> wrote: >>>> On Fri, Jul 12, 2019 at 5:22 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >>>> > I frequently do WebKit development in older versions of macOS to >>>> > diagnose old OS specific regressions, and having to install Python 3 >>>> > each time I install an old OS is too much of a trouble. >>>> >>>> I understand it would be a hassle. :/ But please consider it relative >>>> to the additional difficulty of rewriting all of webkitpy to support >>>> multiple versions of python at the same time, or setting up a wrapper >>>> layer of bash scripts around all of our python scripts to enter a >>>> virtualenv before executing the real script. >>> >>> Yeah, and it sounds strictly better that the trouble is handled by people >>> who maintain Python code who presumably more about Python than a random >>> WebKit contributor who may not know how to setup virtual environment in >>> Python, etc... >>> >>> Again, the argument that the difficulty can be overcome and it's a minor >>> inconvenience isn't convincing. I can, for example, suggest that we should >>> just build WebKit using the latest version of clang. Anyone who uses a >>> system that doesn't come with the latest release of clang should just build >>> clang instead. There is a significant cost in having to support MSVC and >>> GC++ so we should just use clang everywhere and only the latest version >>> like Chromium does. >>> >>> Each team & person has a different preference & perspective when it comes >>> to tooling. Please don't break someone else's working workflow based on >>> your preference. >>> >>> - R. Niwa >>> > -- > - R. Niwa > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
