Problem with ddollar buildpack(s)

[step21]

Hi, pursuant to https://github.com/progrium/buildstep/blob/master/builder/config/buildpacks.txt the multipack https://github.com/ddollar/heroku-buildpack-multi is supported. I want to use it to run https://github.com/benbalter/word_diff This worked fine when testing on heroku, but I want to move it to Docker. I have a very basic Dockerfile, as http://blog.tutum.co/2014/04/10/creating-a-docker-image-from-your-code/ says that buildstep will automatically detect what to install. However, it seems buildstep only installs java stuff (maybe even more then it has to) and no libreoffice or ruby stuff.
docker-build output: http://pastebin.com/XxgRhXRL
Dockerfile: http://pastebin.com/0AGGLZmD
Probably I am just missing something obvious ... but anyway, any help appreciated.

[mjonuschat]

I think are using a different buildstep, probably this one: https://github.com/tutumcloud/buildstep
The tutum buildstep works a bit different.

[step21]

Well, I am using a prebuilt docker-image as a base image, that is true. But as far as I know the actual buildstep included in the image is the same. As you can see at the link above, they link to progrium/buildstep and the list of supported buildpacks. So no, it is the same buildstep. But run from a docker image prebuilt by tutum, yes.

[mjonuschat]

The root of the problems seems to be that due to shell globbing the detection for the java buildpack gets run before the multi buildpack. As the java buildbacks detects an appropriate app no further detection is being executed.

The workaround for the time being is defining the multi-buildpack as a custom buildpack, this will get run instead of any other buildpack. See the README on how to do that.

@progrium What's your take on the problem. I see two solutions. The easy way out - remove the multi buildpack and treat it like any other custom buildpack (since it never worked as intended) - or maybe add a counter to the buildpack installation so that the installation directories get prefixed with a number. Then the globbing of the buildpacks honors the installation order. Doing the latter in the current setup would be rather complicated, to the best of my knowledge xargs doensn't provide a way to have a counter. Looking at https://github.com/gliderlabs/herokuish/blob/master/include/buildpack.bash#L11 it seems feasible with herokuish.

[progrium]

Well even though it's arguable this is terrible design, I think it's a
reasonable solution to hardcode the multi buildpack to run first if it
exists:
https://github.com/gliderlabs/herokuish/blob/master/include/buildpack.bash#L84

An improvement on this design is to have configurable buildpack hoisting,
where multi is the default value.

Anyway, if that's the issue, then this shouldn't be an issue in Herokuish...

On Mon, Feb 16, 2015 at 7:14 AM, Morton Jonuschat [email protected]
wrote:

The root of the problems seems to be that due to shell globbing the
detection for the java buildpack gets run before the multi buildpack. As
the java buildbacks detects an appropriate app no further detection is
being executed.

The workaround for the time being is defining the multi-buildpack as a
custom buildpack, this will get run instead of any other buildpack. See the
README on how to do that.

@progrium https://github.com/progrium What's your take on the problem.
I see two solutions. The easy way out - remove the multi buildpack and
treat it like any other custom buildpack (since it never worked as
intended) - or maybe add a counter to the buildpack installation so that
the installation directories get prefixed with a number. Then the globbing
of the buildpacks honors the installation order. Doing the latter in the
current setup would be rather complicated, to the best of my knowledge
xargs doensn't provide a way to have a counter. Looking at
https://github.com/gliderlabs/herokuish/blob/master/include/buildpack.bash#L11
it seems feasible with herokuish.

—
Reply to this email directly or view it on GitHub
#137 (comment).

Jeff Lindsay
http://progrium.com

[mjonuschat]

Sounds good to me.