Move layer argument to $1 for bin/build and bin/develop

[jkutner]

As described in #28, this change moves the <layers[EIC]> argument to the $1 position for both bin/build and bin/develop.

[sclevine]

I don't have a strong opinion here. I would encourage @nebhale and @jkutner to discuss. If we can't come to an agreement, we should consider alternative interfaces to either of those proposed.

[nebhale]

This seems to be an optimization for people who won't use all the features at the expense of those who will. Is this an accurate characterization? If so, why do we want to target this group? Why don't we want to optimize for buildpacks that make use of all of the features available in the spec?

[jkutner]

My intention is to reduce friction for the base case. In some sense, that does mean optimizing for people who won't use all the features, at least in the beginning.

I want to target this group because it will help grow an ecosystem. I want us to do everything we can to increase adoption and implementation of buildpacks. A healthy and strong ecosystem will be key to the success of buildpacks. Small points of friction can add up and make the buildpack experience unattractive, which works against that goal.

This particular issue (the order of arguments) stands out to me as a point of friction for people trying to implement their first buildpack or a buildpack that is very simple. Every buildpack will use the layer directory, but only some will use the platform and plan.

Thus, I'm arguing for arguments in order of significance.

I did some analysis of the existing v2 buildpacks used on Heroku (there are thousands). I selected about a hundred that are the most commonly used, well-maintained, and not written by Heroku. Of those, only 18% reference $3 (the ENV_DIR).

For advanced buildpack authors, I don't consider the arg order a big concern. Most will use platform and layer directories, and a few will use plan. But we'll all be very familiar with the spec, and relying on tools like libbuildpack.

We have a spec to encourage the community to adopt it. We should make that adoption onramp as easy and frictionless as possible.

All that said, I understand where you're coming from @nebhale . I also understand the tradeoffs in my proposal. Ultimately, I want the best thing for buildpacks overall, and these discussions are an important part of that process, so let's keep at it.

[sclevine]

This change is now on https://github.com/buildpack/lifecycle/tree/spec-28-great-layer-merger.