Passing arguments to the PEP517 sipbuild.api backend

[Michał Górny]

On Sun, 2022-05-08 at 15:06 +0200, Michał Górny wrote:
> On Sat, 2022-05-07 at 15:19 +0100, Phil Thompson wrote:
> > On 07/05/2022 12:37, Michał Górny wrote:
> > > On Sat, 2022-05-07 at 10:54 +0100, Phil Thompson wrote:
> > > > On 07/05/2022 10:33, Michał Górny wrote:
> > > > > On Sat, 2022-05-07 at 10:12 +0100, Phil Thompson wrote:
> > > > > > On 06/05/2022 14:51, Michał Górny wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > I'm one of the maintainers of Python packages in Gentoo.  Lately we've
> > > > > > > been working on transitioning from the legacy "setup.py install"
> > > > > > > workflow to PEP517 build backends.  As part of that, I'd like to work
> > > > > > > on switching the packages relying on sip -- starting with recently
> > > > > > > released update to python-poppler-qt5 but eventually including PyQt.
> > > > > > > 
> > > > > > > Unfortunately, I can't find a way to pass options to the PEP517 backend
> > > > > > > in the way that it is possible to the sip-build executable.  Is it
> > > > > > > possible to inject options currently?  If not, could you please add
> > > > > > > such
> > > > > > > a possibility?  The config_settings dictionary of build_wheel() method
> > > > > > > seems to be the usual method of doing that (cf. setuptools accepting
> > > > > > > {"--global_option": [...]}, though admittedly that double-dash is weird
> > > > > > > there).
> > > > > > > 
> > > > > > > TIA.
> > > > > > 
> > > > > > The sipbuild.api backend currently ignores any config settings because
> > > > > > (as it says in the comments) I wasn't aware of a frontend that seemed
> > > > > > to
> > > > > > support the feature so I couldn't test it properly.
> > > > > > 
> > > > > > Do you have your own frontend or are you using pip (or similar)?
> > > > > > 
> > > > > 
> > > > > Yes-ish.  I've written gpep517 for our needs [1] but the more common
> > > > > build [2] package also supports passing config settings, e.g.:
> > > > > 
> > > > >   gpep517 build-wheel --output-fd 1 --wheel-dir dist/ \
> > > > >     --config-json '{"--global-option": ["--foo"]}'
> > > > > 
> > > > >   python -m build -nw --config-setting=--global-option=--foo
> > > > > 
> > > > > [1] https://pypi.org/project/gpep517/
> > > > > [2] https://pypi.org/project/build/
> > > > 
> > > > So the config_settings argument passed to build_sdist() and
> > > > build_wheel() would be...
> > > > 
> > > > {'--global-option': '--foo'}
> > > 
> > > For build case, yes, this.  If I add a debug print into build_meta:
> > > 
> > >   {'--global-option': '--foo'}
> > > 
> > > However, if you pass multiple arguments with the same key, it turns 
> > > into
> > > a list, e.g.:
> > > 
> > >   $ python -m build -nw --config-setting=--global-option=--foo \
> > >       --config-setting=--global-option=--bar
> > > 
> > > yields:
> > > 
> > >   {'--global-option': ['--foo', '--bar']}
> > > 
> > > To account for this weird syntax, the setuptools backend checks
> > > if "--global-option" is a string, and converts it to list.
> > > 
> > > gpep517 passes the literal dict from unserialized JSON.
> > > 
> > > I'd imagine sipbuild would need to use a similar logic, i.e. something
> > > like:
> > > 
> > >   args = config_settings.get("args", [])
> > >   if isinstance(args, str):
> > >     args = [args]
> > > 
> > > if you want to support build as it currently works.  Personally, I just
> > > need gpep517 support, so the hack wouldn't be necessary.
> > 
> > The next snapshot should allow you to do...
> > 
> > python -m build --config-setting=--qmake=/path/to/qmake
> 
> Thank you a lot!  I can confirm that it works.
> 
> However, there seems to be one limitation: it doesn't permit passing
> the same option multiple times, i.e. the equivalent of:
> 
>   sip-build --qmake-setting QMAKE_CXX=\"clang++\" \
>     --qmake-setting QMAKE_CXXFLAGS=\"-foo\"
> 
> FWICS I can get the same result by using newlines inside the value,
> i.e.:
> 
>   sip-build --qmake-setting "QMAKE_CXX=\"clang++\"
>     QMAKE_CXXFLAGS=\"-foo\""
> 
> so this is not a blocker for me.  Still, you may want to consider it
> while the code is still warm.

Unfortunately, it turns out that I was wrong -- support for multiple
values seems to be necessary for --disable/--enable options of PyQt.

-- 
Best regards,
Michał Górny