Closed kloczek closed 6 months ago
You do not have pygobject (the gi
module) installed as a test dependency.
No I didn't. Just added pkgconfig pygobject-3.0
dependencoes to build env and loos like it solved the issue.
I think that it would be good to add dependency('pygobject-3.0')
to main meson.build.
I think that it would be good to add dependency('pygobject-3.0') to main meson.build.
Actually no .. dependency('pygobject-3.0')
it installs pygobject
header files and in this case it is missing python module so probably better would be add something like import('python').find_installation('python', modules: ['pygobject']))
.
Yep .. just tested and add to build dependencies pygobject
modules fixes the issue.
But it doesn't want the pkg-config file, which is the development component useful for compiling against the pygobject C header.
It just wants to be able to perform a runtime import (import gi
), so you need the python3-gobject module, not the python3-gobject-devel development package.
But it doesn't want the pkg-config file, which is the development component useful for compiling against the pygobject C header.
It just wants to be able to perform a runtime import (
import gi
), so you need the python3-gobject module, not the python3-gobject-devel development package.
Yep and that is why I've added that better would be add checking for pygobject
python module (which provides gi
drecrory).
I'm not sure what to do with this.. This sounds like a downstream packaging issue? It seems solved now? Or is there anything that needs to be done upstream? Thanks!
I'm not sure what to do with this.. This sounds like a downstream packaging issue? It seems solved now? Or is there anything that needs to be done upstream? Thanks!
As I wrote looks like in meson it is missing cecking dependecy (depends()
call) for pygobject .
Tricky.. one really doesn't need the pygobject .pc file, e.g. the Fedora and Debian packaging don't have this either. That kind of runtime dependency is not what dependency() is good at.
As I pointed out above, checking for a dependency()
would unreasonably add an additional distro package to Debian/Fedora build dependencies.
OK .. mesom provides python modules dependencies checking. Something like below should probably do what is needed here 🤔
py_deps = import('python').find_installation('python3', modules: ['pygobject'])
That's the distro package name, not the python module name.
And it's fairly common for gi
to have overrides that cause import gi
to work, but not provide anything. This is why packages need to explicitly depend on python3-gobject if they use it, in addition to whichever packages might happen to provide gi overrides.
So just checking for gi
won't help anyway.
And either way it's still a packaging issue.
In some cases I added a
try:
import ....
except Exception as e:
print("Missing dependencies: %s" % str(e))
sys.exit(77)
block. Then the test just skips, and things are "fine" in some way. Obviously, you should still pull in the runtime dependency. But it makes it clear that this is a problem for you to solve and you can ignore it if you chose to do so.
That said, one does not want to accept a skipped test like this in CI for example.
That's the distro package name, not the python module name.
pip shows
$ pip show PyGObject
Name: PyGObject
Version: 3.43.1.dev0
Summary: Python bindings for GObject Introspection
Home-page: https://pygobject.readthedocs.io
Author: James Henstridge
Author-email: james@daa.com.au
License: GNU LGPL
Location: /usr/lib64/python3.8/site-packages
Requires:
Required-by:
so pygobject
as checked module name should be OK.
yep ..
$ pip show pygobject
Name: PyGObject
Version: 3.43.1.dev0
Summary: Python bindings for GObject Introspection
Home-page: https://pygobject.readthedocs.io
Author: James Henstridge
Author-email: james@daa.com.au
License: GNU LGPL
Location: /usr/lib64/python3.8/site-packages
Requires:
Required-by:
Pip shows the pip package name, not the python module name.
The pip package name is usually the same as the distro package name (or at least very similar, modulo prefixes indicating the relation to python).
The python ecosystem prefers to call the thing you're viewing a "distribution" name, though. ;)
...
The point is, that meson only provides functionality for verifying that a module is importable. It will test modules: ['pygobject']
by attempting to run import pygobject
. And failing.
Please. Accept that I know what I'm talking about here. I am upstream for meson, I know how meson works.
Pip shows the pip package name, not the python module name.
OK so .. py_deps = import('python').find_installation('python3', modules: ['gi'])
And it's fairly common for
gi
to have overrides that causeimport gi
to work, but not provide anything. This is why packages need to explicitly depend on python3-gobject if they use it, in addition to whichever packages might happen to provide gi overrides.So just checking for
gi
won't help anyway.
At the moment, meson.build checks for python and g-ir-compiler
, and if both are found, enables the test:
if python.found()
if g_ir_compiler.found()
test('umockdev.py', python,
args: ['-Wd', '-Werror::PendingDeprecationWarning', '-Werror::DeprecationWarning',
testsdir / 'test-umockdev.py'],
depends: [preload_lib, umockdev_typelib],
suite: 'fails-valgrind')
endif
endif
I suppose this could grow a test for the python gi
module; this is enough, as Fedora's python3-gobject-base
provides nothing aside the gi
module, so I'm not entirely sure what @eli-schwartz really means with "So just checking for gi won't help anyway".
@kloczek perhaps you can send a PR with what you would like to see here? Thanks!
I already explained it, but maybe this will do a better job:
It's possible to install: gi.overrides.FooBar
as a python module. If you do this, python will think gi
is installed, but it might not be.
One way to work around this is to make four packages instead of two, so that FooBar is one package, gi.overrides.FooBar
is a second package, gi
is a third package, and python3-gobject is a fourth package.
This works as long as you step carefully, i.e. checking for gi
is semantically incorrect even if it sometimes works by accident.
The correct way to check is, of course, to actually run some test code from the gi
module to verify that it's in good working order. The modules:
kwarg does not work for gi
, and never will.
FTR: I'm not going to do anything about this myself. I don't understand what you mean/want in the above comments. I'll be happy to review a PR of course. Thanks!
See above -- this isn't actionable, at least from my side.
I'm using gobject-introspection 1.75.4.