On 17 June 2017 at 10:25, Donald Stufft <don...@stufft.io> wrote: > > On Jun 16, 2017, at 5:01 PM, Nathaniel Smith <n...@pobox.com> wrote: > > If someone wants to experiment with this, then it's possible within the PEP > 517 framework to write a 2.7-compatible backend that searches the system for > a python 3 install and then uses it. I'm not sure it's a good idea, but you > can do it :-). > > > > I just want to hammer this specific point home a bit more. The only real > requirement on Python version PEP 517 puts into place is that you write the > API that the frontend will call in the version of Python the frontend is > running under. What you do beyond that is entirely up to you, including > running a different version of Python or something that’s not written in > Python at all. > > The only “downside" to this really is that your options if that build system > isn’t available is to have some sort of fallback (in which case why have the > other thing at all?) or just error out. However I don’t think this is a > solvable downside, because in either case if you’re running on py3 and the > build backend needs py2, there’s nothing really for a frontend to do here > except bail out.
Right, from PEP 517's point of view, running an external build backend like scons/waf/meson under Python 3 to produce Python 2.7 wheels (or even vice-versa) is the same as running any other external binary as part of the build process. The *downside* of doing it that way is that it forces wrappers around those tools (like enscons) to choose between the following two options for 2.7 support: - retain 2.7 compatibility in the backend tool, declare it as a dependency in build-system.requires - run the backend as an external application, losing the ability to automatically install it However, even though I acknowledge that as an unfortunate limitation, I think it would still be better to tackle doing something about it as a separate proposal that improves support for external dependencies. It just highlights that if/when we move forward with that idea, we should have a "pycli" category of external dependencies that specifically handles scripts that can be installed via a tool like `pipsi` based on a PyPI dependency specification (as opposed to arbitrary applications handled by the system package manager). The semantics of a "pycli" external dependency would then be "Install into a dedicated virtual environment using the latest installed Python", with a separate "py2cli" for tools that are currently still Python-2 only. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
