vacation: handle compressed non-tar archives

[mboldt]

Summary

Add support for compressed files that are not tar archives.
In particular, my buildpack has a dependency that is a gzipped executable.

Use Cases

My use case is the Elm compiler, which is distributed as a gzipped executable.

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement. (I believe I have signed the CFF CLA before.)
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs) (No issues to link)
• 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).

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Mikey Boldt (74e615a, 9d768b2)

[ForestEckhardt]

Hey there @mboldt, this change looks pretty good and I like the overall idea. Before moving forward however, the PR does not currently pass the unit test for this repo. If you could get those going green that would be fantastic. You can run the test locally with go test ./....

[mboldt]

Unit tests fixed; apologies for missing that before.

[ForestEckhardt]

@mboldt It looks like there are still a couple of stale name in the example_test.go if you could just give those a quick update that would be much appreciated.

[mboldt]

Yes, just noticed and fixed that, and fixed one more thing the linter caught. Thank you.

[ForestEckhardt]

@paketo-buildpacks/tooling-maintainers Seeing how this seems like a major version change I would like to get one other person to sign off on this.

[sophiewigmore]

@ForestEckhardt / @paketo-buildpacks/tooling-maintainers These changes make sense to me, although I am wondering if there is a way we could introduce these changes in a non-breaking way? I understand this is the best implementation to reduce complexity/code duplication by making the types non-specific to tar. I haven't personally contributed much to vacation so I'll defer to you on that Forest

[mboldt]

Some thoughts on various approaches:

1. Do not handle non-tar archives.
   • Pros: No code change ;-)
   • Cons: Supports fewer use cases.
2. Keep the current PR implementation.
   • Pros: Implementation makes sense.
   • Cons: breaking change. (I don't know how wide the impact would be...do consumers use the specific archive types?)
3. Just leave the type names alone (i.e., keep Tar) even though they don't assume tar archives.
   • Pros: doesn't break.
   • Cons: it is misleading. (IMHO that's enough to discount this.)
4. Add the new non-tar types, and leave the existing assume-tar types alone. Internally, use the non-tar types exclusively (e.g., when decompressing a generic archive), effectively deprecating the assume-tar types.
   • Pros: Keeps the internal usage clean; doesn't force breaking change.
   • Cons: Keeps the (internally) unused code around. Code duplication.
   • This seems worthy of discussion if the breaking changes are a concern.
   • Note: (Just for completeness) could also try to use both the non-tar and assume-tar types, but that seems like useless complexity...don't see any upside.

Hopefully that helps us think through some of these options. I am happy to rework the implementation based on discussion/feedback.

[sophiewigmore]

@mboldt Thank you for laying these out! It's probably worth pointing out that breaking changes are not the end of the world for us. This would extend out to all of our buildpacks that use this package, which is quite a few, but it's still not the end of the world by any means. I brought it up just in case there was a clever way we could get around it, but it's definitely not a blocker to getting this merged in. I'll think on the options you've laid out

Edit: This actually won't be a huge issue at all, we are already going to be cutting a major release with some other changes, and these changes will be used within other packit packages. All good with these changes as is.