No, systemctl creates the folder, it’s only because I was manually writing the override file that I needed to create the folder first.
Not at all.
rather than edit on the fly at install with sed you would just create a folder and write to a blank file (if it needs editing at all) and when it comes to further updates (to the service unit not just the path) a git pull does it all, writing a new file into place is far more complex as you need to ascertain and apply the right path.
a script only needs to be written once (with the pull method), not every time the service unit is updated, a git pull is always sufficient!
Also don’t forget that whilst we are indeed accommodating the ability to install to other paths, 99% of the time the paths will all be the same, why edit at all for that 99% of the time? hardcode the service unit as
/usr/local/bin/emonhub.py (or whatever it ends up as) and only “edit” if a different path is needed, that is much, much simpler than editing and writing the same exact file with the same paths on the fly a majority of the time. It doesn’t make sense to complicate the install or updating for the huge majority just to accommodate the very few that need a different path, when there is a way to only edit the minority!
For years we have struggled against the /home/pi and emonpi specific paths, now we are opening up to using more generic paths “instead” not “as well as” (backward compatibility aside), we do not need to overly complicate things by making it mandatory to edit/specify every path. That seems to be over-correcting the issue somewhat.
/usr/local/bin will be present on far more installs and distros than
/home/pi and that is what we are addressing here, if someone wants to then install to
/some/other/less/mainstream/place then there is a mechanism to do that via the drop-in, we do not need to build the whole install and every update around the few users that might do that!
Yes, because they do not use cloning as an update method, we need to embrace the fact we do it that way, or do it another way, not half one way and half the other, that’s how we get in these positions.
If or when we move any software to a release package (debian, pip or just a download zip & install) then yes, the finalised file would be written or copied into place and not symlinked as there would obviously be either a better mechanism or no need to update frequently. I’m all for that, but we’re not there yet, whilst we are frequently cloning to make changes, symlinks are the better tool for the job.