PR #6 introduced a change to move certain directories up to the root and remove the original because certain buildpacks expect this. However, this caused unintended side effects for the Ruby buildpack as reported in #8 .
Heroku "sources" bash scripts that buildpacks leave behind in the .profile.d directory. This is for example used to add node, ruby and python into the PATH when the dyno launches. However, buildpacks are free to leave excutables wherever they leave. My original idea was to simply copy the .profile.d directory to the root of the app so that Heroku can invoke the scripts. However, most buildpacks use relative paths to the executables in those shell scripts, so by moving them, you break them. My quick fix was to also move the executables/files from well-known locations, but that (as reported in #8) seems to break certain buildpacks.
A more stable solution I'd like to propose:
Don't copy anything anywhere. Create a bash script in .profile.d (in the root) that invokes the .profile.d scripts in all the subdirectories, with then working directory set to that subdirectory. Like this, the relative paths stay correct and we can leave executables/files where they are and buildpacks can continue to do whatever they want. According to the Heroku documentation, .profile.d scripts are executed in no particular order, so this behaviour shouldn't be that hard to replicate.
PR #6 introduced a change to move certain directories up to the root and remove the original because certain buildpacks expect this. However, this caused unintended side effects for the Ruby buildpack as reported in #8 .
Heroku "sources" bash scripts that buildpacks leave behind in the
.profile.ddirectory. This is for example used to addnode,rubyandpythoninto thePATHwhen the dyno launches. However, buildpacks are free to leave excutables wherever they leave. My original idea was to simply copy the.profile.ddirectory to the root of the app so that Heroku can invoke the scripts. However, most buildpacks use relative paths to the executables in those shell scripts, so by moving them, you break them. My quick fix was to also move the executables/files from well-known locations, but that (as reported in #8) seems to break certain buildpacks.A more stable solution I'd like to propose:
Don't copy anything anywhere. Create a bash script in
.profile.d(in the root) that invokes the.profile.dscripts in all the subdirectories, with then working directory set to that subdirectory. Like this, the relative paths stay correct and we can leave executables/files where they are and buildpacks can continue to do whatever they want. According to the Heroku documentation,.profile.dscripts are executed in no particular order, so this behaviour shouldn't be that hard to replicate.https://devcenter.heroku.com/articles/buildpack-api#profile-d-scripts
I'll try to come up with a working example.