I spoke too soon. This works for the standard output, but I'm using `Mix.Task.run` to run the tasks I'm running (which is necessary). Those don't use `Mix.shell`, they go straight to `IO.warn` (or something similar, haven't investigated yet.
So I'm not sure if there is some way to tell Elixir from "inside the house" to redirect stderr in some way. > On Dec 27, 2024, at 8:46 PM, Zachary Daniel <zachary.s.dan...@gmail.com> > wrote: > > FWIW this is all I’m going to need I think :) > > https://hexdocs.pm/mix/1.12.3/Mix.html#shell/1 > >> On Dec 26, 2024, at 7:37 PM, Zachary Daniel <zachary.s.dan...@gmail.com> >> wrote: >> >> >> I agree that it shouldn’t be default. I’m only looking for it because I have >> tooling that runs `mix deps.compile` after adding new deps, and in *that* >> context it could be argued that it makes less sense. But in reality the same >> argument may apply and warnings shouldn’t be hidden. It just makes the >> package installation pretty noisy. The idea of capturing stderr would be >> reasonable and I can explore that. >> >>> On Dec 26, 2024, at 6:20 PM, Simon McConnell <simonmcconn...@gmail.com> >>> wrote: >>> >>> >>> Brandon, you can do things about some of the warnings, e.g. go to the repo >>> and submit at PR. >>> >>> Consider a monorepo where path dependencies are used. I don't believe that >>> hiding each dependency's warnings by default would be ideal. >>> >>> On Friday, 27 December 2024 at 1:15:44 am UTC+11 Brandon Gillespie wrote: >>>> I'd love this feature. IMHO, it should be default. >>>> >>>> Perhaps when doing deps compile just print out at the end "X lines of deps >>>> warnings suppressed, see with --show-deps-warnings" >>>> >>>> Typically I ignore all deps warnings, because there's never been anything >>>> I can do about what they're complaining about. >>>> >>>> Actually thinking about it from a UX perspective, what if: >>>> >>>> (a) compile wrapper detects a warning >>>> (b) check of there's an update >>>> >>>> Then print the compiling "string" with no newline, and append to it >>>> relevant information afterward. Like: >>>> >>>> >>>> ===> compiling cowlib[NL] — good compile, no change >>>> >>>> ===> compiling hackney: 14 warnings ignored[NL] >>>> >>>> ===> compiling hackney: 14 warnings ignored, new version 10.20.30 >>>> available[NL] >>>> >>>> >>>> >>>> And at the end add a message like --show-deps-warnings to see full warning >>>> output. >>>> >>>> >>>> >>>> >>>> On 12/25/24 11:59 PM, José Valim wrote: >>>>> Can you explain why it is important to disable those warnings? It is just >>>>> a way to clean the output? What if there is a warning that is indeed >>>>> pointing to a flaw or violation that must be addressed? >>>>> >>>>> In any case, worst case scenario, if the user already has to install >>>>> igniter, you could inject an igniter.deps.compile task that call >>>>> deps.compile but captures stderr? >>>>> >>>>> >>>>> >>>>> José Valim >>>>> https://dashbit.co/ >>>>> >>>>> >>>>> On Thu, Dec 26, 2024 at 03:55 Zach Daniel <zachary....@gmail.com <>> >>>>> wrote: >>>>>> This is something I'd like to have for igniter. Part of what we do is >>>>>> download a dependency from hex and recompile the app. I'd like to find a >>>>>> way to clean up the output when doing something like >>>>>> >>>>>> `mix igniter.new --install ash`. I'd like to be able to suppress all of >>>>>> the information about deps compilation or potentially just suppress the >>>>>> warnings. >>>>>> >>>>>> I know this has been discussed before, and I agree with the general idea >>>>>> that allowing people to suppress warnings with an option is a slippery >>>>>> slope that leads in a bad direction. However, I think for *dependencies >>>>>> specifically* that principle doesn't necessarily hold. >>>>>> >>>>>> Would it be on the table to potentially disable or hide warnings while >>>>>> dependencies are compiling, on an opt-in basis. like `mix deps.compile >>>>>> --no-warnings`? >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "elixir-lang-core" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to elixir-lang-co...@googlegroups.com <>. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/94c2e48c-caa6-4dc6-bfda-f7b7e09c9eean%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/94c2e48c-caa6-4dc6-bfda-f7b7e09c9eean%40googlegroups.com?utm_medium=email&utm_source=footer>. >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "elixir-lang-core" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to elixir-lang-co...@googlegroups.com <>. >>>> >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KcKf_Lxf7DycHCm6ivC9t73fTJhdkZ_Jnj0%2BabbCqEYA%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KcKf_Lxf7DycHCm6ivC9t73fTJhdkZ_Jnj0%2BabbCqEYA%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "elixir-lang-core" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to elixir-lang-core+unsubscr...@googlegroups.com >>> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/elixir-lang-core/91363918-cc96-483e-8795-2e0fb053879en%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/91363918-cc96-483e-8795-2e0fb053879en%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/E97164B7-3860-493D-A3BF-4608005DBFEF%40gmail.com.
