I’ve come across a couple cases now where a binary-only package that just provides commands need paths ./configured in for state / config, but don’t have any persistent service component.
I’ve been wondering how to approach this besides having a dummy service and requiring it to be started at least once before any of the commands get used. What I’m thinking of doing right now is adding a setup_runtime_env script to the build artifact that initializes the /hab/svc paths manually and maybe copies some config, and then creating a parallel bin-wrapped directory that has a copy of every command from the build’s bin wrapped in a script that calls setup_runtime_env first to expose instead. That would have the added bonus of making commands work while binlinked that need env
Are there any problems with that approach I’m not seeing? Another approach I’m not considering? More blessed paths on the horizon?
That has some additional weirdness of a lazy-loaded per-user daemon which might end up getting dealt with by turning its daemon into a singleton hab service which would solve the svc path issue.
I’ve encountered the issue in this thread in other purer cases before though, where a binary command needs some space for config/state without having any persistent daemon element
This also strikes me as somewhat related to https://github.com/habitat-sh/habitat/issues/5161 where you have a library package that needs a hook to do some setup tasks. This is different in that #5161 is dealing with library packages that would eventually be referenced by a service package but your scenario would never be tied to a service package. Perhaps there is a way to consolidate this scenario into that issue by introducing a hab pkg configure command that would run a configure hook defined for that package regardless of whether it was ever meant to be run as a service.
@mwrock great point. It seems that non-service packages are sometimes going to have a need for environmental initialization and it would be great to be able to accomplish that through a new central hook
There might be a connection to https://github.com/habitat-sh/habitat/issues/4493 in that if binlinks get a wrapper, that wrapper could ensure the configure hook has been run. I like things being done as late as possible, but that approach wouldn’t address the case in the issue you linked to of libraries needing to register themselves
Maybe something in the middle, where there is a new hook that can be manually invoked with something like hab pkg configure that hab pkg exec and the binlink wrappers handle making sure has been run once first if present