Sounds easy? Well, it should have been. I’m not talking about a “Hello, World!” (although it is more or less on the same level for me). The goal was to write a set of three MQTT clients that properly talk with each other and interact nicely.

So I had to learn Python and MQTT on the same day. Should not be an issue after 40 years of programming. But it quickly turned out that the Python library/package for MQTT on Ubuntu was heavily outdated (1.6), and did not supply all the functions the documentation and examples (2.0) asked for. Using pip3 didn’t work, as it complained that the package structure was maintained by the OS. In the end, I had to virtualize the python3 system and pip3 the 2.0 package there and run it.

After about three hours, I had the clients working as they should. Yes, I think MQTT is a good base for the next project.

  • sloppy_diffuser@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    7
    ·
    5 months ago

    I recommended checking out package managers that will simplify using whatever version of a library you want with project level virtual environments.

    I haven’t done heavy python dev since 3.7, so I don’t know the full landscape of options these days, but here are some references to dig into.

    https://python-poetry.org/ is the one I started using as the first step up from pip.

    It looks like there are some new contenders like hatch, rye, and pdm: https://dev.to/adamghill/python-package-manager-comparison-1g98.

    There is also pixi referenced from the comments in that article: https://github.com/prefix-dev/pixi

  • Andrew@piefed.social
    link
    fedilink
    English
    arrow-up
    4
    ·
    5 months ago

    I think virtualizing the python environment (with venv) has become quite common, although my only evidence is that the server I’m using to send this was written in Python and uses one.

    • Treczoks@lemmy.worldOP
      link
      fedilink
      arrow-up
      3
      ·
      5 months ago

      The next step will be to implement two of the clients on RPi Pico W boards. The documentation on MQTT on that platform has quite some potential for improvement, to put it mildly.

      • sloppy_diffuser@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        3
        ·
        5 months ago

        Having done some MQTT IoT work in the past, dropping a couple resources:

        https://github.com/eclipse/mosquitto - CLI interface and C bindings. I’ve only used the CLI interface. Its a nice way to test communication with a remote broker.

        RabbitMQ /w MQTT plugin - Message queue based on AMQP. We ran this as the server in a container. There maybe others options like 0MQ (been a few years so don’t know every option). I had my clients post to a wild card topic so that I could consume a single device or all devices. Consumption is not with MQTT though. We’d use AMQP on that side.

  • 1984@lemmy.today
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    5 months ago

    I can recommend arch for programming once you get tired of the Ubuntu outdated thing. Having the latest packages is awesome.

    • sloppy_diffuser@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      1
      ·
      5 months ago

      While I have nothing against an arch recommendation, I wouldn’t rely on my distro when there is tooling to get any version of a library directly from pypi.

  • half_built_pyramids@lemmy.world
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    5 months ago

    That just sounds like a normal Linux session to me. I recently barely stumbled my way through using file pointers as the pins for my simple bbb project.

    • Treczoks@lemmy.worldOP
      link
      fedilink
      arrow-up
      4
      ·
      5 months ago

      Well, in my professional tasks, I have smoothed out about all trouble spots long ago. So having two new fields at once to work on and deal with their teething problems reminded me of times long ago.