So i found a workaround way to do this that should be ok int he majority of cases. Basically you include a helper file and keep all your non-chef-resource helper methods in it. If you have any methods you want to share that contain Chef resources, then put them in the base class for your libraries and subclass it. May not be the best way but fine for now.
I think that’s just because helpers methods are there to provide helpers not to provide definitions (deprecated) or custom resource which are the way to go to ‘glue’ together multiples chef resources and custom ruby code.
Helpers/library are there to make helpers methods to avoid to repeat yourself in recipe code, not to make custom providers based on chef resources.
That Docker resource you linked looks like a really strange implementation
to me and perhaps isn’t a good one to base anything on. I don’t know why
they have done it that way instead of either A) defining an actual
action_init and action_service actions on that resource and chaining where
necessary (it should be idempotent and thus not matter) or B) just put the
resources directly in the actions that need them.
Perhaps it was an attempt at being more DRY, but in this case it’s resulted
in some pretty dodgy behaviour, like the fact the stop action actually
starts then stops the service instead of just skipping if it’s already
stopped (i.e. it’s not idempotent).
I’m sure your use case is different, but maybe if you show a little more of
what you’re trying to do do the question could be ‘how can I get this to
work inside a custom resource?’ instead of trying to get it to work in a
helper where it likely isn’t a good fit.