This was used in OTP releases where the normal OTP_VERSION file
is unavailable.
If checking against OTP minor versions and patch levels
is needed again, revert this commit and commit mentioned below.
Context: 1be8deda73
warning: Credo.CLI.Command.Info.Output.Default.print_after_info/4 is undefined or private. Did you mean:
* print/2
│
4 │ use Credo.CLI.Output.FormatDelegator,
│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
│
└─ lib/credo/cli/command/info/info_output.ex:4: Credo.CLI.Command.Info.InfoOutput.print_after_info/4
warning: :warnings_as_errors is deprecated as part of Code.get_compiler_option/1
(elixir 1.18.3) lib/code.ex:1597: Code.get_compiler_option/1
(elixir 1.18.3) lib/code.ex:1572: anonymous fn/2 in Code.compiler_options/1
(elixir 1.18.3) lib/enum.ex:2546: Enum."-reduce/3-lists^foldl/2-0-"/3
(elixir 1.18.3) lib/code.ex:1571: Code.compiler_options/1
(pleroma 2.9.1-77-g8ec49c59-elixir-1-18+test) lib/pleroma/application.ex:104: Pleroma.Application.start/2
(kernel 10.2.6) application_master.erl:295: :application_master.start_it_old/4
warning: :warnings_as_errors is deprecated as part of Code.put_compiler_option/2, instead you must pass it as a --warnings-as-errors flag. If you need to set it as a default in a mix task, you can also set it under aliases: [compile: "compile --warnings-as-errors"]
(elixir 1.18.3) lib/code.ex:1710: Code.put_compiler_option/2
(elixir 1.18.3) lib/code.ex:1573: anonymous fn/2 in Code.compiler_options/1
(elixir 1.18.3) lib/enum.ex:2546: Enum."-reduce/3-lists^foldl/2-0-"/3
(elixir 1.18.3) lib/code.ex:1571: Code.compiler_options/1
(pleroma 2.9.1-77-g8ec49c59-elixir-1-18+test) lib/pleroma/application.ex:104: Pleroma.Application.start/2
(kernel 10.2.6) application_master.erl:295: :application_master.start_it_old/4
Mastodon uses the Sec-Websocket-Protocol header to send the auth token. It is not clear if this is a violation of the RFC, but Mastodon is not the first application in the wild to use this header for authentication purposes. Phoenix does not allow accessing this header, so we work around it temporarily with a minor patch to Phoenix 1.7.14. We will reach out to Phoenix to discuss how to make this use case possible.
This is for streaming media to ffmpeg thumbnailer. The existing implementation relies on undocumented behavior.
Erlang open_port/2 does not officially support passing a string of a file path for opening. The specs clearly state you are to provide one of the following for open_port/2:
{spawn, Command :: string() | binary()} |
{spawn_driver, Command :: string() | binary()} |
{spawn_executable, FileName :: file:name_all()} |
{fd, In :: integer() >= 0, Out :: integer() >= 0}
Our method technically works but is strongly discouraged as it can block the scheduler and dialyzer throws errors as it recognizes we're breaking the contract and some of the functions we wrote may never return.
This is indirectly covered by the Erlang FAQ section "9.12 Why can't I open devices (e.g. a serial port) like normal files?"
https://www.erlang.org/faq/problems#idm1127
