Add profile buildpack detect and build logic

[gcemaj]

closes: #7
closes: #8

Signed-off-by: gcemaj gcemaj@bloomberg.net

[dmikusa]

@samj1912 I was playing with this buildpack and noticed that my .profile is getting sourced twice. I think that's because the lifecycle is doing it once and now the exec.d is doing it. Is that what you'd expect to happen also? If so, what do you think the buildpack can/should do here to try and prevent that from happening?

I'd like to think that in most cases the .profile script should be OK to run twice, but we can't know that. It could have some side effect that breaks the second time it's run or causes other problems. Is it possible to get the lifecycle version when the buildpack runs? We could add a check so that the buildpack does not pass detection on versions of the lifecycle where it still runs the profile script.

[gcemaj]

@samj1912 I was playing with this buildpack and noticed that my .profile is getting sourced twice. I think that's because the lifecycle is doing it once and now the exec.d is doing it. Is that what you'd expect to happen also? If so, what do you think the buildpack can/should do here to try and prevent that from happening?

I'd like to think that in most cases the .profile script should be OK to run twice, but we can't know that. It could have some side effect that breaks the second time it's run or causes other problems. Is it possible to get the lifecycle version when the buildpack runs? We could add a check so that the buildpack does not pass detection on versions of the lifecycle where it still runs the profile script.

i thought there was a way to say what version of the lifecycle a BP was compatible with. We just need to make this be only compatible with versions that are new enough right?

[dmikusa]

In regards to the duplicate runs, an update from a Slack conversation. It sounds like the removal from .profile support in the lifecycle will require a buildpack API change. If that's true, then we can specify in buildpack.toml that we require buildpack API 0.9 (or whatever version it ends up being). That would prevent someone from using this buildpack with an older setup & causing problems.

[sambhav]

Some minor comments. Otherwise LGTM.

[sambhav]

I don't think the buildpack actually needs any provides/requires?

[gcemaj]

so the plans should be empty?

[dmikusa]

This question has come up before. I know that in Paketo we always put something, even if provides/requires match-up like here. I don't totally know why that is though. If it's historic reasons or if there's some function to it. It logically seems redundant though, since you are providing your own requirement. The only thing that I can think of off the top of my head that this would do is to ensure there's an entry in the buildplan, but this buildpack isn't looking at the buildplan so idk.

@gcemaj did you by chance try it with an empty buildplan? Did it work the same?

[gcemaj]

i have not yet, can i do it locally?