Passing arguments to the PEP517 sipbuild.api backend

[Phil Thompson]

On 08/05/2022 19:22, Michał Górny wrote:
> 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.

Should be fixed now.

Thanks,
Phil