Service paths/config without service?

Habitat Help
#1

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?

Is there a way to render template files without running a service?
#2

This is definitely not something that we’ve got any kind of formal support for at the moment.

What you describe may work; I’d say it’s certainly worth an experiment, in any event.

Are you able to share more concrete details around your use case, just to anchor the discussion?

#3

@christophermaier yep, here’s the use case I’m working through now: https://github.com/habitat-sh/core-plans/pull/1620

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

#4

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.

#5

@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

1 Like