I’m not sure how adding another location and a symlink “simplifies” the service file, surely just call the emonhub.py direct from the service unit if that is your sole aim, essentially all you will be doing is moving the content of /home/pi to /opt. My reasons for doing the “clone&symlink” is that conf files are found where conf files live and the executables or binaries are found where the executables/binaries live etc etc tec.
I see no good reason to symlink just the executable that a service unit needs to find, the service unit path is dictated by us it can literally be anywhere, the reason for putting the executables in /usr/local/bin is so that users can find them where they should be. The fact we clone them to a repo in /opt is just a easy backdoor way to keeping things updated, “our dirty little secret” if you like, yes, you and I would look to /opt for the source code as we are developers and the “clone&symlink” method is primarily aimed as providing an easy way to develop, the fact we still use that version control system as a package manager after deployment isn’t something the average user will be aware of or even need to know if well implemented. And yet any budding developer/programmer will recognise exactly what is going on once they see the symlinks.
These are 2 separate things IMO, no we shouldn’t necessarily “stick to using /opt”, regardless of whether we use EnvironmentFile, in fact if you stick to using /opt, there is no need to use EnvironmentFile as the path is never likely to change, it’s no different to using /home/pi where every setup does have a user pi’s homedir to install to.
Using EnvironmentFile is not entirely a bad idea IMO, but it is a very “init.d” way of doing things, it’s how the emonhub init.d service has worked for years with the default paths in /etc/default/emonhub. The “systemd” way of doing things is to use edit files. But which ever way you get the path into the service unit, it is only necessary if you want to be able to vary the path, if all installs are going to be in /opt why edit the unit at all?
I would rather see the whole src folder symlinked to /usr/local/bin and that path used in the service unit as that will serve 99% or more users and be a FHS compliant’ish use of cloned repo’s. Only on more exotic installs that don’t use FHS will that path need to be overridden by a drop-in file, it seems pointless to add the confusion of mandatory edits, environment files or non-fhs paths just to serve those very few users when there is a perfectly good other way. Remember /usr/local is going to be present on far more installs than /home/pi is, the issues with installing to /home/pi are not being carried forward to /usr/local.
If we can’t do it that way, then yes I guess the next best thing is just use /opt directly and forget about /usr/local symlinks, this is marginally better than “all in /home/pi”, but it is pretty much the same thing different location. (But it is better than splitting the src folder, that’s just a no no!)
I can’t see why symlinking the src folder has caused such a reaction. Does it matter if all the other files from the src folder can be found at the same place (as expected)? You were happy to create a folder just to sit the emonhub.py symlink inside, but symlinking the folder rather than using mkdir, so that all the src content is kept together is apparently a problem, the path to emonhub.py would be exactly the same!
It’s clear this is not a decision that should be made off the cuff so again I suggest we hold off putting any changes into live repo’s.
