Propose that we remove the `yj` binary from stacks

[dmikusa]

Summary

Propose that we remove yj. Readable.

Checklist

• [ ] I have viewed, signed, and submitted the Contributor License Agreement.
• [ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• [ ] I have added an integration test, if necessary.
• [ ] I have reviewed the styleguide for guidance on my code quality.
• [ ] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[sophiewigmore]

I approve in principle, but I'm holding off giving the official thumbs-up for a week or two while we wait for feedback from the community as to whether anyone is using yj during build time.

@fgrehm I recall you filed https://github.com/paketo-buildpacks/stacks/issues/128 a while ago, I was wondering if the removal of yj from the stacks would have any effect on your use cases?

[ForestEckhardt]

This would potentially make things more difficult for individuals that are trying to write bash buildpacks as there is no other command line toml parser available to them. It we are ok with telling people that if they want to write extension buildpacks for our buildpacks that the must write in a language where they can parse their own toml if necessary then that is fine just wanted to call out the use case that we are blocking.

[dmikusa]

This would potentially make things more difficult for individuals that are trying to write bash buildpacks as there is no other command line toml parser available to them. It we are ok with telling people that if they want to write extension buildpacks for our buildpacks that the must write in a language where they can parse their own toml if necessary then that is fine just wanted to call out the use case that we are blocking.

We can also provide guidance that authors should include any dependencies required by their buildpack. i.e. bundle yj if you require it.

[robdimsdale]

It we are ok with telling people that if they want to write extension buildpacks for our buildpacks that the must write in a language where they can parse their own TOML if necessary

Yeah, I think this is fine. I don't think there's any reason why the stack should provide this tool. It seems just as intuitive to say that the buildpack should be responsible for parsing TOML as it does to say the stack provides a mechanism to do it (especially a mechanism that few/none of the Paketo buildpacks use).

If it was zero cost to continue to provide yj in a multi-arch environment, I might be inclined to opt for that. However, even in that scenario there would still be the concern that it's wasted space on the fileystem and an extra layer. But the fact that it's more effort to continue to support it in a multi-arch environment makes me inclined to remove it.

[dmikusa]

Could we call for final comments on this one? It's been three weeks and the last comments were two weeks ago.

[ForestEckhardt]

I am happy to put this in FCP @paketo-buildpacks/stacks-maintainers I think that this is your call.

[sophiewigmore]

Psst @paketo-buildpacks/stacks-maintainers (@brayanhenao @robdimsdale) we are waiting for at least one more of you to give a thumbs up on this PR.