Passing arguments to the PEP517 sipbuild.api backend
Michał Górny
mgorny at gentoo.org
Sun May 8 14:06:03 BST 2022
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.
--
Best regards,
Michał Górny
More information about the PyQt
mailing list