Open kloczek opened 2 years ago
Here is pytest output:
Hi! You need either a real Secret Service daemon (e.g. gnome-keyring), or a mock implementation, like what I am using here (maybe without coverage, you don't need it): https://github.com/mitya57/secretstorage/blob/bf1e831954626d58551050d520f1fff2942a48cd/.github/workflows/main.yml#L19-L25
mock implementation
Which one module provides that?
I've been trying to run over dbuss-run-session but it didn't help
+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-secretstorage-3.3.2-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-secretstorage-3.3.2-2.fc35.x86_64/usr/lib/python3.8/site-packages
+ dbus-run-session -- /usr/bin/pytest -ra
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.13, pytest-7.1.2, pluggy-1.0.0
rootdir: /home/tkloczko/rpmbuild/BUILD/secretstorage-3.3.2
collected 26 items
tests/test_collection.py FFFFsssss [ 34%]
tests/test_context_manager.py F [ 38%]
tests/test_dhcrypto.py . [ 42%]
tests/test_exceptions.py FFF [ 53%]
tests/test_item.py FFFFFFFFFFF [ 96%]
tests/test_unlocking.py s [100%]
Which one module provides that?
In my tests on GitHub I use libsecret's mock service. It is not part of binary packages, but it's present in upstream git repository, which I clone: https://gitlab.gnome.org/GNOME/libsecret.
I've been trying to run over dbuss-run-session but it didn't help
dbus-run-session alone is not enough. As I said, you need either gnome-keyring (or another implementation) or mock service (and tests/run_tests.py
script).
Debian packaging uses the first approach — with gnome-keyring, see https://salsa.debian.org/python-team/packages/python-secretstorage/-/tree/debian/master/debian/tests.
dbus-run-session alone is not enough. As I said, you need either gnome-keyring (or another implementation) or mock service (and
tests/run_tests.py
script).
Why not run all that on test env preparation inside pytest session to make testing less complecated? 🤔
I never thought about that. Patches are welcome :smile:
Sorry I'm not bread and butter python developer I'm just more humble general packaging specialist .. so I have quite broad knowledge and exp but not so deep to be able easyly write such pieces. Nevertheless observing on large scale (I have now packagesd +1k python modules) what other python modules aredoing I think that future changes in this case could go in exactly that direction.
May I ask what exactly currently needs to be done to be able sucessfully run pytest based test suite? 🤔 Simple I need to implemet that in build procedure to have some baseline ..
https://gitlab.gnome.org/GNOME/libsecret
or download the tarball from https://download.gnome.org/sources/libsecret/ and unpack it.dbus-run-session -- python ./tests/run_tests.py /path/to/libsecret/libsecret/mock-service-normal.py
. Where /path/to/libsecret
is path to unpacked/cloned tree.A bit odd testing procedure based on libsecret private code which is not installed by libsecret
by the install target.
Other thing is that IIRC pytest provides testing session initialization in which is possible to star whatever is needed for test units.
If that libsecret
is useful outside of that project I would ask to libsecret
maintainer to provide that as regular python module which libsecret
and your project may have listed in build/test dependencies. 🤔
A bit odd testing procedure based on libsecret private code which is not installed by libsecret by the install target.
I agree it's weird, but it was the only Secret Service mock implementation I found, so I thought it's better to re-use it rather than write my own.
If that libsecret is useful outside of that project I would ask to libsecret maintainer to provide that as regular python module which libsecret and your project may have listed in build/test dependencies.
If you ask them to install the Python module somewhere, that would be nice.
If you ask them to install the Python module somewhere, that would be nice.
I think that you shpold try to do that .. only because I would be not the best person which could express needs of making that code kind of official non-private code available for other libsecret
consumers like your project 😄 😋
Just only FTR updated pytest output for 3.3.3. Here is pytest output:
Sorry, I wanted to file a bug against libsecret but it got buried under a bunch of other tasks. Thanks for bringing it to the top again, I have done that now:
👍 👀
I'm packaging your module as an rpm package so I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.
python3 -sBm build -w --no-isolation
build
with--no-isolation
I'm using during all processes only locally installed modulesHere is lis of modules installed in build env: