I am running integrity with a delayed job worker which handles builds. I recently when the build is run that the PATH has been prefixed with "/path/to/integrity/vendor/gems/../../bin". Clearly I'd like my project builds to be independent of the particular versions of files like rake etc. that integrity has vendored. It would be good if integrity removed its bin directory from the PATH before running the build, any suggestions on the best way to do this? J.
On Thu, Dec 3, 2009 at 9:51 AM, Joel Chippindale <joel.chippindale@gmail.com> wrote: > I am running integrity with a delayed job worker which handles builds. > > I recently when the build is run that the PATH has been prefixed with > "/path/to/integrity/vendor/gems/../../bin". Clearly I'd like my > project builds to be independent of the particular versions of files > like rake etc. that integrity has vendored. > > It would be good if integrity removed its bin directory from the PATH > before running the build, any suggestions on the best way to do this? I agreed but at the same time I am tempted to say its the build script's job to setup the PATH.
You're right it's fair enough to expect the build instructions to set the path explicitly if it needs something special. However I would integrity to be as inconspicuous as possible WRT to the build, and so the least surprising thing would be keep integrity's path additions out of the path when building. If we were agreed it was a bug (or at least not desirable) then I'll put a patch together. J. 2009/12/4 Simon Rozet <srozet@engineyard.com>: > On Thu, Dec 3, 2009 at 9:51 AM, Joel Chippindale > <joel.chippindale@gmail.com> wrote: >> I am running integrity with a delayed job worker which handles builds. >> >> I recently when the build is run that the PATH has been prefixed with >> "/path/to/integrity/vendor/gems/../../bin". Clearly I'd like my >> project builds to be independent of the particular versions of files >> like rake etc. that integrity has vendored. >> >> It would be good if integrity removed its bin directory from the PATH >> before running the build, any suggestions on the best way to do this? > > I agreed but at the same time I am tempted to say its the build script's > job to setup the PATH. >
On Tue, Dec 8, 2009 at 5:27 PM, Joel Chippindale <joel.chippindale@gmail.com> wrote: > You're right it's fair enough to expect the build instructions to set > the path explicitly if it needs something special. > > However I would integrity to be as inconspicuous as possible WRT to > the build, and so the least surprising thing would be keep integrity's > path additions out of the path when building. > > If we were agreed it was a bug (or at least not desirable) then I'll > put a patch together. I totally agree that the current behavior breaks the least suprise rule; the amount of people having issues related to that proves it. I sure am interested in a patch. I might not merge it depending on the complexity it adds, though. Nevertheless, this behavior should at least be clearely documented. Thanks, -- Simon Rozet <simon@rozet.name> http://atonie.org
I've already mentioned this fix in another thread "fun environment bug with the bundler", but just to make ti clear this commit http://github.com/econsultancy/integrity/commit/43d88db381aa5141d4f06fba402c5178d518c657 should apply cleanly to master and resolve this problem of environment changes made by bundler leaking into the builds. J. 2009/12/9 Simon Rozet <simon@rozet.name>: > On Tue, Dec 8, 2009 at 5:27 PM, Joel Chippindale > <joel.chippindale@gmail.com> wrote: >> You're right it's fair enough to expect the build instructions to set >> the path explicitly if it needs something special. >> >> However I would integrity to be as inconspicuous as possible WRT to >> the build, and so the least surprising thing would be keep integrity's >> path additions out of the path when building. >> >> If we were agreed it was a bug (or at least not desirable) then I'll >> put a patch together. > > I totally agree that the current behavior breaks the least suprise > rule; the amount of people having issues related to that proves it. > > I sure am interested in a patch. I might not merge it depending on the > complexity it adds, though. Nevertheless, this behavior should at > least be clearely documented. > > Thanks, > > -- > Simon Rozet <simon@rozet.name> http://atonie.org >