Resolving transitive runtime dependencies

I have 2 packages.

  1. eye a ruby process monitor
  2. a rails web app that I use eye to run

I do this so that I can have a single habitat package that spins up both puma and delayed_job processes

My eye package depends on core/ruby (currently 2.5.1)
My rails app depends on core/ruby/2.4.2 and on chrisortman/eye

When I build my rails app, it errors because of the conflict between the ruby dependencies. Assuming I’ve done all the PATH, GEM_HOME, GEM_PATH gymnastics, I should be able to run eye with ruby 2.5.1 and have it launch puma with ruby 2.4.2

My question, can I void the warranty and tell habitat this is ok to build?

I think it should be okay :tm:

If you are getting conflicts out of the plan-build dep-solver I’m not sure how you’d work around it though.

Yeah, that’s the problem is that I can’t build the package because it detects these conflicts

Ultimately I think I’ll build a package that links against the old version of ruby because that is probably the simplest thing to do.

This pattern seems to creep up once in a while though (I think bundler comes to mind) where I want a package for the ruby gem but now you have competing requests for which version of ruby to link to.
Maybe it would make sense for me to make a my-ruby-with-deps package