There are (at least) two broad ways to go about fixing this:
fix up the service’s path/environment
recognize that foobar has runtime dependencies that aren’t being properly specified and try to fix the package itself
Since you’re asking about the former, I’ll focus on that first. I’m not certain since I don’t use HM, but I imagine in supports most of the same systemd service options as NixOS. The most relevant is:
systemd.user.services.<name>.path
Packages added to the service’s PATH environment variable. Both the bin and sbin subdirectories of each package are added.
Type: list of (package or string)
Default:[ ]
The latter is the more useful fix, but the specifics can depend on what language/ecosystem foobar comes from and whether this is just your own private package or something defined in nixpkgs (in which case I’d say the unspecified dependency is a ~bug).
and it seems to me that the Home Manager way for defining systemd services is just a simple conversion from attr. set to systemd format (INI or TOML) so I will need to specify Service = { Environment = "PATH=...
The very dirty solution I just found is to do exactly what you described, declare your path as Environment=PATH=/run/current-system/sw/bin/ or /home/your_user/.nix-profile/bin/.
Very weird to me that it doesn’t work as it does with system services.
Edit:
The solution was right in front of my eyes the whole time:
I had read that thread before but didn’t quite understand that this is exactly what we were looking for.