jdev - 2022-01-09

  1. Sam

    Are there any other scriptable (or controllable through a socket or something) XMPP clients that anyone is aware of? I can't get scansion running on either my laptop (Fedora, no Lua 5.2) or my CI machine (FreeBSD, lua5.2 named differently than the hardcoded path scansion uses, no GNUMake features)

  2. jonas’

    did you consider docker?

  3. Sam

    Yes, but the integration tests currently expect to spin up a process and do process-y things. I could write an entirely separate way of doing HTTP requests, but that's a lot of extra stuff

  4. jonas’

    docker run is process-y

  5. Sam

    And takes time to start up a giant bloated environment, then I still have to make HTTP requests.

  6. jonas’

    http requests for what?

  7. jonas’

    also, does aioxmpp qualify as a scriptable XMPP client? ;)

  8. jonas’

    it is very scriptable, in python ;)

  9. Sam

    hmm, that's a fair point, maybe I could just use a library. I'd have ot write a lot more boilerplate to connect and what not, but it would probably be easier to run everywhere

  10. jonas’

    you might be interested in the framework.py in aioxmpp/examples which is meant for examples, but abstracts ~everything away

  11. jonas’

    you could also (ab-)use the aioxmpp end-to-end test runner which also abstracts most of that away

  12. jonas’

    depends on your use case I guess

  13. Sam

    RE http I was assuming you meant run scansion in server mode where it accepts HTTP posts in Docker, that's the only install method the docs show. I guess I could run docker separately, find a way to upload scripts into the container, then do a docker exec to run them, but that's even more work (and we haven't talked about figuring out network communications); it's just not worth it to add docker to the mix

  14. Sam

    Thanks, I'll look into those (use case is integration tests)

  15. jonas’

    sure, but integration tests can mean a lot of different things :)

  16. jonas’

    openfire runs nearly the complete aioxmpp test suite in their github actions

  17. jonas’

    openfire runs nearly the complete aioxmpp e2e test suite in their github actions

  18. jonas’

    that obviously only makes sense in a server scenario

  19. jonas’

    Sam, oh, ok, the only way *I* know to run scansion is to feed it .scs files

  20. Zash

    Upload scripts? Volume mount?

  21. jonas’

    so my approach would've been: (1) make scansion docker image, (2) docker run -v "$(script):/script:ro" scansion:latest /script, (3) done.

  22. jonas’

    so my approach would've been: (1) make scansion docker image, (2) docker run -v "${script}:/script:ro" scansion:latest /script, (3) done.

  23. Sam

    oh yah, forgot that was a thing; that could work. Either way, it's just too much more work to use Docker. I'd prefer to keep this to "things I can install locally and just run"

  24. jonas’

    you do you. I embraced docker to run strange tools locally. took away lots of headaches.

  25. Sam

    It's a fair point, it would get rid of the dependency issues

  26. jonas’

    especially for test tools… I want them reproducible, easily run and not have to fiddle with them every time I upgrade $something. they should work when I need them. docker is good at that.

  27. Sam

    Still, probably easier to just use something else; I hadn't thought of just using a library instead of a thing already setup as a client, but I do think that could work easily enough, so that may be the first thing to try then fall back to using Docker if I can't get that working

  28. Sam

    Docker is no different than installing them locally in that regard (in CI, that is). I'm running a disk image, it has the same stuff on them that don't change.

  29. jonas’


  30. Sam

    *facepalm* I should have realized aioxmpp won't be available on FreeBSD either. I can install it from pip of course, but that means manually figuring out and installing dependencies since it depends on external stuff like libxml2 that have to be installed separately. Oh well, let's see if this takes me less time to figure out than trying to patch scansion did

  31. jonas’

    *whisper* dooooockeeeeeer *whisper* :D

  32. Sam

    > error: can't find Rust compiler Okay, now onto installing my third system just to run a script I guess.

  33. jonas’

    that indicates that your version of pip is out of date

  34. jonas’

    or that there is no pre-built pyopenssl for that platform

  35. Sam


  36. Sam

    Upgrading pip didn't seem to help; let's search the system packages for pyopenssl. Thanks for the help.

  37. jonas’

    oh, it's cryptography, not pyopenssl

  38. jonas’

    https://pypi.org/project/cryptography/ this one

  39. Sam

    That seems to have been installed a dependency already (possibly when I just installed pyopenssl from the system packages), so fingers crossed it works this time

  40. Sam

    oh yes, that completed, so that's step one anyways

  41. jonas’

    depending on how pip is configured on your system, it may ignore system-wide installed packages

  42. jonas’


  43. defanor

    On controllable through a socket or something clients -- it's indeed fairly close to just using a library, but I'm currently hooking rexmpp to Emacs with a wrapper introducing an XML interface over stdin/stdout, <https://git.uberspace.net/rexmpp/tree/emacs/xml_interface.c>. Though the interface is ad hoc; I thought it might be nice to design it more carefully, to hook other libraries to the same Emacs client (and possibly for other purposes, like integration testing multiple libraries via the same language-agnostic interface), but expecting it to be tricky to decide which functions such a generic interface should provide, since library APIs can be quite different.

  44. qy

    Wasn't there that cli xmpp client? Without a tui, i mean

  45. qy

    Yeah, xmppc

  46. qy

    If you want to just script in shell, maybe that?

  47. junaid

    Anyone available to take a peek at one of my XMPP hobby projects and provide constructive criticism? prvt me on junaid@yax.im

  48. qy

    Sam: https://codeberg.org/Anoxinon_e.V./xmppc

  49. Zash

    Or the various sendxmpp implementations, and clix

  50. Sam

    Thanks, I hadn't heard of that one, I'll look into it. I am actually already testing against the perl sendxmpp (though really I should probably find a different one), but those tend to be rather limited as clients since they're really just meant to send a one off message or a file or something.

  51. qy


  52. Zash

    I imagine you're after stuff like sending queries and blocking until a response before proceeding.

  53. Sam

    Not necessarily blocking, but yah, just something I can remote control and tell it to do things. I'm doing this with McAbber right now (which has a way to open a socket you can execute commands through) and sendxmpp (which is CLI obviously), but mostly my client integration tests are lacking (and both of those are unmaintained and don't have a lot of modern functionality)

  54. junaid

    Sam, have ya maybe considered throwing a bot at the problem? like using errbot as a base, and then code any additional/desired logic as a plugin for it? https://errbot.readthedocs.io/en/latest/index.html

  55. Sam

    I'm not familiar with that one either, I'll look into it, thanks

  56. junaid

    Sam, you say "remote control and tell it to do things". may i ask what you actually wish the client/bot to do? like, would sending raw non-message stanzas be a hard/soft/no requirement for you?

  57. Sam

    Not necessarily; there's no single thing I want it to do, I'm just writing integration tests against various clients and libraries. Different modules may be tested against different things depending on what supports what.

  58. Sam

    For example I currently test receiving pings using both mcabber and sendxmpp, testing sending in-band bytestreams against a prosody module, and for receiving IBB I'm thinking about testing against aioxmpp using a small wrapper script. It doesn't have to be one client that does everything.

  59. Sam

    Raw non-message stanzas aren't actually super useful, I can just do that internally. The idea is to make sure my implementation is compatible with other existing implementations.

  60. junaid

    Sam, I guess this is specifically for testing mellium components. in which case, any established XMPP bot framework should be fine. considering that you're writing mellium, it does seem like then it would be best for the XMPP tester to be written using mellium itself. but then you almost kinda run into a chicken-vs-egg problem. I say "almost" because you could always (manually?) verify the functionality of one mellium version against another established client/bot and then, once confirmed, you could use that version to verify functionality of later mellium versions.

  61. Sam

    oh the testing stuff is already written and works, I'm just looking for more clients to run it against mostly