On 2024-04-28 19:26:00+0000, Thomas Weißschuh wrote: > On 2024-04-28 17:34:42+0000, Richard W.M. Jones wrote:
> [..] > > It should run without any google.* modules installed, and also if any > > combination of google.* modules are installed. In all cases it ought > > to load the mocked module from tests/test-gcs and ignore the installed > > google.* modules, or if it can't do that (see my commit message above) > > it should skip the test. > > > > For me, that all works. > > I missed the tests/test-gcs/google/api_core directory. > > > However I found last week that there's something seriously weird about > > the google.* modules (not to mention Python module loading in > > general), so I can believe the test might not work in some > > combination. > > > > Nevertheless, the commit as proposed is definitely wrong. The gcs > > test does not (or should not) use any installed google.* module, so if > > it does then that's a bug of some kind. > > Agree. > > I narrowed it down to python-protobuf being installed. > It creates /usr/lib/python3.12/site-packages/google . > > I think this should be a namespace package, which is handled specially, > But I'm not sure if the problem is in python-protobuf, the Python import > machinery or the setup by test nbdkit testsuite. > > Will investigate. PEBKAC... I first ran the testsuite against v1.38.1 where the gcs test failed. Then I went to master and tried to fix it, blindly creating tests/test-gcs/google/__init__.py. This broke the namespace package import logic and with it the test on master again. So please just disregard all of this noise. Thomas _______________________________________________ Libguestfs mailing list -- guestfs@lists.libguestfs.org To unsubscribe send an email to guestfs-le...@lists.libguestfs.org
