`port select python` and qtwebengine

Chris Jones jonesc at hep.phy.cam.ac.uk
Sun Jun 2 15:47:35 UTC 2019


The behaviour of any given portfile should never depend on whatever ‘port select’ choices a user may have made. The base changes you describe below seem and overly complex way to solve the problem in general. If a build requires a given python version, but provides no options to control how to get that version then that really is a deficiency in upstreams build system. In cases like this your best bet (other than to report the issue back upstream) I think is to patch the build system directly, for instance changing whatever you need to force the use of the correct macports python command.


> On 2 Jun 2019, at 4:03 pm, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> Hi,
> I just learned that the QtWebEngine build process has a hard dependency on python 2 and cannot be configured to use a specific python interpreter exclusively. In other words, it fails if a user apparently used `port select python` to make a python 3 interpreter the default one.
> I think "base" doesn't have any mechanisms in place to avoid such failures? For instance, a `port select` implementation where the generic command (here, `python`) is not a symlink but a script that can be controlled via an env. variable or a dedicated cli argument (a bit like Qt's qtchooser; could address safety concerns)? Even a simple API to check within the Portfile if the user made an incompatible selection (and raise an error) would be preferable over letting the build fail with unknown side-effects.
> R.

More information about the macports-dev mailing list