this post was submitted on 07 Jun 2024
25 points (100.0% liked)

Linux

5491 readers
653 users here now

A community for everything relating to the linux operating system

Also check out !linux_memes@programming.dev

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago
MODERATORS
 

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.

top 10 comments
sorted by: hot top controversial new old
[–] sloppy_diffuser@sh.itjust.works 7 points 6 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_s@piefed.social 5 points 6 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.

[–] 1984 3 points 6 months ago (1 children)

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 3 points 6 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.

[–] Blaze@lemmy.zip 3 points 6 months ago (1 children)
[–] Treczoks@lemmy.world 3 points 6 months ago (1 children)

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 3 points 6 months ago (1 children)

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.

[–] Treczoks@lemmy.world 1 points 6 months ago

I'm running a mosquitto here as the broker, and use MQTT Explorer for debugging.

[–] half_built_pyramids@lemmy.world 0 points 6 months ago (1 children)

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.world 4 points 6 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.