Using Reticulum as a daemon after PEP 668

[ThomasFreedman]

I created a shared Reticulum instance started by systemd at bootup, which ran as a daemon process under a particular user account created for that purpose.

PEP668 under debian 12 prohibits installation of globally available modules via pip without using the --break-system-packages option. That essentially forces one of 2 solutions for cron and systemd scripts:

1. install RNS as a global system module with pip using the --break-system-packages override option
2. installing and hard coding paths to an account's virtual python environment and activating it to start a local RNS instance.

Using the system's package manager to install system / global modules is the preferred way to go, but I don't believe Reticulum is available that way.

For now I am using option 1 until I hear of a better solution, but am open to suggestions.
As painful as it is to adapt to PEP 668 I believe it is the right way to go, even tho I never had problems the old way. None that I'm aware of anyway. Perhaps I'm just lucky :)

[faragher]

I've just been breaking system packages like Kit-Kat bars. :D

Some thoughts:

Can the daemon simply change the path environment to the venv RNS in installed in?

Is it time to begin packaging RNS in system packages? I have zero experience with that, or even pip repos. I feel that's the wrong way to go, what with pip being basically the same thing with fewer dependencies and steps, but apparently Debian disagrees.

[zirpu]

I recommend running it via pipx.

…

-a -- Allan Bailey ***@***.***

On Tue, Jul 2, 2024 at 5:14 PM faragher ***@***.***> wrote: I've just been breaking system packages like Kit-Kat bars. :D Some thoughts: Can the daemon simply change the path environment to the venv RNS in installed in? Is it time to begin packaging RNS in system packages? I have *zero* experience with that, or even pip repos. I feel that's the wrong way to go, what with pip being basically the same thing with fewer dependencies and steps, but apparently Debian disagrees. — Reply to this email directly, view it on GitHub <#517 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAJ744B5ZYZPEBKI7NW2DZKM67HAVCNFSM6AAAAABKIL6MBOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSNBSGEZDI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Swissbandit]

I was disappointed in the documentations when pipx came into debian.
As a beginner it was easy to play around with python, especially on the raspberry pi.
suddenly it was harder to set up and use, and simple answers like how correct shebangs look like where not documented.
its time to research for a decent docu again and learn to properly use it.

one thing i found recently was the flag --global this may help setup demons.
i still struggle to upgrade properly though.

[kc1awv]

You can try this out. I created a gist that has some basic instructions on how to get RNS to run as a service with an unprivileged user.

rnsd as local user for fun and profit

[ThomasFreedman]

Thanks for the reminder @kc1awv, I totally forgot about the linger option for user systemd units. I used that quite a bit about 5 years ago, and you're right it should work for a shared RNS instance running under a specific user account.

As for deb / rpm etc native op sys packages, I'm not sure if it's too early for that or not, but it would make it much easier for people to use RNS, and it would probably bring more eyes to bare on it, both good and bad. That's also a support issue to do the packaging work & keeping them updated.