I’ve run into another new problem, that I don’t think existed previously. In my plan I have a few dependencies that provide binaries:
pkg_scaffolding="core/scaffolding-ruby" pkg_deps=(core/curl finalze/imagemagick core/file)
and I SWEAR they used to be runnable from an interactive session within the resulting container when I exported to Docker, as if they were in the path. Now though, they are not, and they do not appear in the path. For example:
~ # curl /bin/sh: curl: not found ~ # /hab/pkgs/core/curl/7.54.1/20180329185356/bin/curl curl: try 'curl --help' for more information ~ # which curl ~ # echo $PATH /bin ~ # ls /bin/curl ls: /bin/curl: No such file or directory ~ #
I’ve looked at my app_env.sh and that’s not doing anything relevant, and I’ve poked around in all the startup and initialization scripts I can think of and haven’t found a place where these binaries are made available to my app. However, my app seems to be able to find them as it is working correctly, but some ancillary support scripts we have do not. They rely on some Ruby gems to do their work, and those gems in turn assume these binaries will be in the path. In the short term, I’ve worked around the problem by symlinking the binaries I know I need into /bin when I need them, but that’s not a sustainable solution.
Is this a change in behavior, or is my memory faulty? I can conceive of a number of ways I could work around this with custom bash profiles for root and all sorts of other nonsense, but it feels like the correct behavior would be for Habitat to add the binaries provided by deps to the path to ensure they are available.