-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 7z container support #2744
Add 7z container support #2744
Conversation
If this allows less complexity in the project, I'm all for it. |
Can this |
rebased |
@nanoxd , if you meant that the "catch-all" notion would reduce complexity, not really. Once the unar base class here is introduced, then, for example, adding Stuffit containers takes only 8 lines of code. And the problems of the "catch-all" class are many: it's literally requesting undefined behavior. I can imagine something like #2654 being complicated by the fact that @muescha if you are curious about how the design decisions were reached, you may refer to #1992 and #2305 . |
relevant Casks must use `depends_on_formula unar`
This will not pass Travis until Homebrew#2744 is merged
this will not pass Travis until Homebrew#2744 is merged
my comment i continued in #3207 |
relevant Casks must use
depends_on_formula unar
Tests are handled similarly to the (updated) PR #1992 -- they will be skipped unless the developer has
unar
installed.The system
/usr/bin/file
cannot recognize7z
files, soextension
andmagic_number
methods were added tocriteria.rb
to aid in determining filetypes.Unlike #1992, this is implemented in terms of an abstract base class
Cask::Container::UnarBase
. We can use the base class to support Stuffit containers and whatever else is desired from the broad number of filetypes supported byunar
. (I plan only 7z, Stuffit, and RAR).Since
unar
provides a consistent interface across many archive types, it would actually be possible to skip having aCask::Container::SevenZip
class entirely in favor of aCask::Container::Unarable
which would come last in the list of container classes and function as a kind of catch-all. However, for both technical and stylistic reasons, I think being explicit is a better approach.