I saw the installation instructions and it makes my sysadmin heart tremble. However, I saw there was a debian dir there, so I tried to make the package. That worked (except a bunch of warnings, but only about the CHANGES syntax or something), but when I try to start it, I get the above. I've tried to create a venv and install it there, but it didn't help, doesn't look like it's interested in the venv at all. I can probably just pip install --break-system-packages, but I really don't want to. Software should be installable cleanly without messing about.
Any idea what can be done to fix this cleanly?
openshop_repeater@openhop-vm.karlsbakk.net:~$ openhop-repeater
Traceback (most recent call last):
File "/usr/bin/openhop-repeater", line 33, in <module>
sys.exit(load_entry_point('openhop-repeater==1.0.5.dev0', 'console_scripts', 'openhop-repeater')())
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/bin/openhop-repeater", line 25, in importlib_load_entry_point
return next(matches).load()
~~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/importlib/metadata/__init__.py", line 179, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.13/importlib/__init__.py", line 88, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 1026, in exec_module
File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/repeater/main.py", line 10, in <module>
from repeater.companion.utils import (
...<7 lines>...
)
File "/usr/lib/python3/dist-packages/repeater/companion/__init__.py", line 6, in <module>
from .bridge import RepeaterCompanionBridge
File "/usr/lib/python3/dist-packages/repeater/companion/bridge.py", line 16, in <module>
from openhop_core.companion import CompanionBridge
ModuleNotFoundError: No module named 'openhop_core'
openshop_repeater@openhop-vm.karlsbakk.net:~$
Hi
I saw the installation instructions and it makes my sysadmin heart tremble. However, I saw there was a debian dir there, so I tried to make the package. That worked (except a bunch of warnings, but only about the CHANGES syntax or something), but when I try to start it, I get the above. I've tried to create a venv and install it there, but it didn't help, doesn't look like it's interested in the venv at all. I can probably just pip install --break-system-packages, but I really don't want to. Software should be installable cleanly without messing about.
Any idea what can be done to fix this cleanly?
openshop_repeater@openhop-vm.karlsbakk.net:~$ openhop-repeater
Traceback (most recent call last):
File "/usr/bin/openhop-repeater", line 33, in <module>
sys.exit(load_entry_point('openhop-repeater==1.0.5.dev0', 'console_scripts', 'openhop-repeater')())
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/bin/openhop-repeater", line 25, in importlib_load_entry_point
return next(matches).load()
~~~~~~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/importlib/metadata/__init__.py", line 179, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.13/importlib/__init__.py", line 88, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 1026, in exec_module
File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/repeater/main.py", line 10, in <module>
from repeater.companion.utils import (
...<7 lines>...
)
File "/usr/lib/python3/dist-packages/repeater/companion/__init__.py", line 6, in <module>
from .bridge import RepeaterCompanionBridge
File "/usr/lib/python3/dist-packages/repeater/companion/bridge.py", line 16, in <module>
from openhop_core.companion import CompanionBridge
ModuleNotFoundError: No module named 'openhop_core'
openshop_repeater@openhop-vm.karlsbakk.net:~$
<!-- github-sync-id:4866675521 -->
FWIW, I'm facing similar, and with following their manage.sh install path… leading to a slightly different missing python module error:
/opt/openhop_repeater/venv/bin/python: Error while finding module specification for 'repeater.main' (ModuleNotFoundError: No module named 'repeater')
And I agree with the frightening nature of that manage script. At one point, I ended up with the project directory completely emptied except for a venv dir!
FWIW, I'm facing similar, and with following their `manage.sh install` path… leading to a slightly different missing python module error:
```
/opt/openhop_repeater/venv/bin/python: Error while finding module specification for 'repeater.main' (ModuleNotFoundError: No module named 'repeater')
```
And I agree with the frightening nature of that manage script. At one point, I ended up with the project directory completely emptied except for a `venv` dir!
<!-- github-comment-id:5209209609 -->
Thanks for raising this. I definitely agree that you shouldn’t need to use pip install --break-system-packages, and that isn’t how the normal installer is intended to work.
I think what you’ve hit here is that the Debian packaging and the current manage.sh installation path have drifted apart somewhat.
The current manage.sh installer deliberately creates a dedicated virtual environment at:
/opt/openhop_repeater/venv
All of the Python dependencies, including openhop_repeater and the hardware dependencies, are installed into that venv rather than into the system Python. The systemd service then runs the repeater using:
So on a normal install there should be no need to bypass Debian’s externally-managed Python protection or use --break-system-packages.
There is also migration code in manage.sh specifically for older installations which used the system Python. It removes old PYTHONPATH entries, changes an old /usr/bin/python3 ExecStart to the venv interpreter, cleans up old system-level Python packages and removes stale source trees which could otherwise shadow the package installed in the venv.
From your traceback:
/usr/bin/openhop-repeater
is being executed and it is loading repeater from:
/usr/lib/python3/dist-packages/
so that installation is definitely going through the system Python rather than the environment that the current installer expects. That also explains why creating a venv manually didn’t help — /usr/bin/openhop-repeater has no reason to use that venv.
The reason manage.sh has become rather large is that it is doing quite a bit more than simply installing a Python package. It currently handles things such as:
creating and maintaining the dedicated venv
creating the repeater service user and permissions
installing the required OS packages
configuring the systemd service
configuring hardware groups such as gpio, i2c, spi, dialout and plugdev
SPI detection/configuration
different radio connection methods, including native SPI and CH341 USB-SPI
udev configuration
Raspberry Pi-specific handling as well as more generic SBC handling
architecture-specific wheels for ARM64, ARMv7 and x86_64
special handling for platforms such as the Luckfox Pico where some binary wheels aren’t available
upgrades and migration from older PyMC/openHop layouts
OTA/web upgrades while keeping those upgrades inside the same venv
So there is unfortunately quite a bit of SBC/radio/platform-specific setup wrapped up in it.
That said, I completely agree with the underlying point: installing the software cleanly shouldn’t require messing with the system Python.
The debian/ directory probably needs some attention because at the moment building the .deb isn’t equivalent to installing through manage.sh. Ideally we should either make the Debian package set up/use the same dedicated venv and service layout, or restructure things so the common installation logic is shared rather than maintaining two different installation paths.
I’d actually be very interested in ideas for improving this. If we can move more of the platform-independent setup out of manage.sh, simplify the packaging, or make a proper .deb the main installation mechanism without losing support for all the different SBC/radio combinations, I’d be very happy to simplify it.
Thanks for raising this. I definitely agree that you shouldn’t need to use pip install --break-system-packages, and that isn’t how the normal installer is intended to work.
I think what you’ve hit here is that the Debian packaging and the current manage.sh installation path have drifted apart somewhat.
The current manage.sh installer deliberately creates a dedicated virtual environment at:
/opt/openhop_repeater/venv
All of the Python dependencies, including openhop_repeater and the hardware dependencies, are installed into that venv rather than into the system Python. The systemd service then runs the repeater using:
/opt/openhop_repeater/venv/bin/python -m repeater.main
So on a normal install there should be no need to bypass Debian’s externally-managed Python protection or use --break-system-packages.
There is also migration code in manage.sh specifically for older installations which used the system Python. It removes old PYTHONPATH entries, changes an old /usr/bin/python3 ExecStart to the venv interpreter, cleans up old system-level Python packages and removes stale source trees which could otherwise shadow the package installed in the venv.
From your traceback:
/usr/bin/openhop-repeater
is being executed and it is loading repeater from:
/usr/lib/python3/dist-packages/
so that installation is definitely going through the system Python rather than the environment that the current installer expects. That also explains why creating a venv manually didn’t help — /usr/bin/openhop-repeater has no reason to use that venv.
The reason manage.sh has become rather large is that it is doing quite a bit more than simply installing a Python package. It currently handles things such as:
* creating and maintaining the dedicated venv
* creating the repeater service user and permissions
* installing the required OS packages
* configuring the systemd service
* configuring hardware groups such as gpio, i2c, spi, dialout and plugdev
* SPI detection/configuration
* different radio connection methods, including native SPI and CH341 USB-SPI
* udev configuration
* Raspberry Pi-specific handling as well as more generic SBC handling
* architecture-specific wheels for ARM64, ARMv7 and x86_64
* special handling for platforms such as the Luckfox Pico where some binary wheels aren’t available
* upgrades and migration from older PyMC/openHop layouts
* OTA/web upgrades while keeping those upgrades inside the same venv
So there is unfortunately quite a bit of SBC/radio/platform-specific setup wrapped up in it.
That said, I completely agree with the underlying point: installing the software cleanly shouldn’t require messing with the system Python.
The debian/ directory probably needs some attention because at the moment building the .deb isn’t equivalent to installing through manage.sh. Ideally we should either make the Debian package set up/use the same dedicated venv and service layout, or restructure things so the common installation logic is shared rather than maintaining two different installation paths.
I’d actually be very interested in ideas for improving this. If we can move more of the platform-independent setup out of manage.sh, simplify the packaging, or make a proper .deb the main installation mechanism without losing support for all the different SBC/radio combinations, I’d be very happy to simplify it.
<!-- github-comment-id:5301054323 -->
Another update… I've been successfully running the repeater via the openhop/openhop-repeater:main docker image.
On the same RPi 4, using the openhop_repeater/manage.sh to install did install and set up many things, but then is unable to start the service as I reported earlier. (ModuleNotFoundError: No module named 'repeater')
Another update… I've been successfully running the repeater via the `openhop/openhop-repeater:main` docker image.
On the same RPi 4, using the `openhop_repeater/manage.sh` to install did install and set up many things, but then is unable to start the service as I reported earlier. (`ModuleNotFoundError: No module named 'repeater'`)
<!-- github-comment-id:5471960927 -->
service openhop-repeater start now actually starts the service, and it runs!
I've just got it to run by manually installing with the following from https://github.com/openhop-dev/openhop_repeater/blob/1.1.1/manage.sh#L660-L663
```sh
/opt/openhop_repeater/venv /bin/python -m pip install \
--upgrade \
--no-cache-dir \
"openhop_repeater[hardware] @ git+https://github.com/openhop-dev/openhop_repeater.git@main"
```
`service openhop-repeater start` now actually starts the service, and it runs!
<!-- github-comment-id:5474038427 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hi
I saw the installation instructions and it makes my sysadmin heart tremble. However, I saw there was a debian dir there, so I tried to make the package. That worked (except a bunch of warnings, but only about the CHANGES syntax or something), but when I try to start it, I get the above. I've tried to create a venv and install it there, but it didn't help, doesn't look like it's interested in the venv at all. I can probably just pip install --break-system-packages, but I really don't want to. Software should be installable cleanly without messing about.
Any idea what can be done to fix this cleanly?
FWIW, I'm facing similar, and with following their
manage.sh installpath… leading to a slightly different missing python module error:And I agree with the frightening nature of that manage script. At one point, I ended up with the project directory completely emptied except for a
venvdir!Thanks for raising this. I definitely agree that you shouldn’t need to use pip install --break-system-packages, and that isn’t how the normal installer is intended to work.
I think what you’ve hit here is that the Debian packaging and the current manage.sh installation path have drifted apart somewhat.
The current manage.sh installer deliberately creates a dedicated virtual environment at:
/opt/openhop_repeater/venv
All of the Python dependencies, including openhop_repeater and the hardware dependencies, are installed into that venv rather than into the system Python. The systemd service then runs the repeater using:
/opt/openhop_repeater/venv/bin/python -m repeater.main
So on a normal install there should be no need to bypass Debian’s externally-managed Python protection or use --break-system-packages.
There is also migration code in manage.sh specifically for older installations which used the system Python. It removes old PYTHONPATH entries, changes an old /usr/bin/python3 ExecStart to the venv interpreter, cleans up old system-level Python packages and removes stale source trees which could otherwise shadow the package installed in the venv.
From your traceback:
/usr/bin/openhop-repeater
is being executed and it is loading repeater from:
/usr/lib/python3/dist-packages/
so that installation is definitely going through the system Python rather than the environment that the current installer expects. That also explains why creating a venv manually didn’t help — /usr/bin/openhop-repeater has no reason to use that venv.
The reason manage.sh has become rather large is that it is doing quite a bit more than simply installing a Python package. It currently handles things such as:
So there is unfortunately quite a bit of SBC/radio/platform-specific setup wrapped up in it.
That said, I completely agree with the underlying point: installing the software cleanly shouldn’t require messing with the system Python.
The debian/ directory probably needs some attention because at the moment building the .deb isn’t equivalent to installing through manage.sh. Ideally we should either make the Debian package set up/use the same dedicated venv and service layout, or restructure things so the common installation logic is shared rather than maintaining two different installation paths.
I’d actually be very interested in ideas for improving this. If we can move more of the platform-independent setup out of manage.sh, simplify the packaging, or make a proper .deb the main installation mechanism without losing support for all the different SBC/radio combinations, I’d be very happy to simplify it.
Another update… I've been successfully running the repeater via the
openhop/openhop-repeater:maindocker image.On the same RPi 4, using the
openhop_repeater/manage.shto install did install and set up many things, but then is unable to start the service as I reported earlier. (ModuleNotFoundError: No module named 'repeater')I've just got it to run by manually installing with the following from https://github.com/openhop-dev/openhop_repeater/blob/1.1.1/manage.sh#L660-L663
service openhop-repeater startnow actually starts the service, and it runs!I just hit this failure again, after upgrading my repeater to
1.1.4:… and again had to manually fix it with the
pipcommand I noted in my reply to this issue last week.If at all useful, this was the output from
manage.shon that upgrade to1.1.4:Click to expand console log
And this was the output from the fix:
Click to expand console log