Hi, 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.
Chris > On 2 Jun 2019, at 4:03 pm, René J.V. Bertin <rjvber...@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.
