-
Notifications
You must be signed in to change notification settings - Fork 3
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 CLI #14
Conversation
|> Enum.drop_while(&(&1 != type)) | ||
|> Enum.drop(1) | ||
|> Enum.take_while(&(&1 not in [:i, :o])) | ||
|> case do | ||
[value] -> value | ||
[_h | _t] = values -> List.to_tuple(values) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's fine for now, but I think we finally gonna need to use something like: https://hexdocs.pm/elixir/1.12.3/OptionParser.html or https://www.erlang.org/doc/apps/stdlib/argparse.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Currently, the API is not parsable by the OptionParser AFAIK - for example, we'd have to have boombox --i input.mp4
instead of boombox -i input.mp4
. Maybe we should adjust to that, but that would require more thinking ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇
closes #9
This PR allows building boombox as a standalone binary and adds a CLI API to call that binary. The API translates to the Elixir API in the following way:
-value
is translated to atom:value
For example,
is equivalent to:
I chose burrito for the building part, because it's the only tool I found that outputs a single binary and requires neither Erlang nor Elixir. When the binary is run for the first time, it extracts the release from itself, stores it under a common location in the system, and calls it. Subsequent runs only call the unpacked release. In our case, the problem is that the uncompressed release weighs over 1,5 GB, because of FFmpeg artifacts which are duplicated for each package that uses FFmpeg and take over 1,4 GB. Thus, building the release and the first run (unpacking) takes a longer while.