Ah yes that makes sense, emonhub is not a single file executable (like log2ram etc) it’s a collection of files and IMO they should all (appear to) be together, I do not think we should be symlinking just the emonhub.py. I was thrown by this bit of your commit when I looked
that’s why I quickly commented that the path should NOT be /usr/share/emonhub
and that the sub-folder was unnecessary, as it looked like you were just creating a folder to put the symlink in (well in fact you were!).
In actual fact whilst the sub-folder doesn’t need to be created, the path with the sub-folder level is correct. What we should be doing is symlinking the emonhub/src
folder to /usr/local/bin
so that the path to emonhub is /usr/local/bin/emonhub/emonhub.py
and the output from
ls -la /usr/local/bin/emonhub
is a symlink to emonhub/src and the output of
ls -la /usr/local/bin/emonhub/
is a full list of all the emonhub source files. (not the repo root, but src root).
I sort of panicked a bit and made a hasty call because these changes are going into the live repo’s, I’m really not comfortable with that. It means we must get it right at every commit because we don’t know when anyone might update. The emonhub logfile is all that needed to be sorted on existing images, the path works fine on the emonSD, once we make a firm choice, implement and test the new paths for the new installer and updater scripts we can then update the old images in a controlled transition, we can’t really alter the emonSD symlink paths now as the repo is in the wrong place ie /home/pi/emonhub
not /opt/emonhub
(or /opt/emon/emonhub
?) unless you plan on chaining symlinks which may bring it’s own issues.
Can we please try and separate “fixing immediate issues with the current image” and “developing the new installer and updater” and get it right, before rolling it out?