Suppress warnings when compiling dependencies

[Zach Daniel]

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`?

[José Valim]

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/

--
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.

[Brandon Gillespie]

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.

To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KcKf_Lxf7DycHCm6ivC9t73fTJhdkZ_Jnj0%2BabbCqEYA%40mail.gmail.com.

[Simon McConnell]

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.

[Zachary Daniel]

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 <simonmc...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/91363918-cc96-483e-8795-2e0fb053879en%40googlegroups.com.

[Brandon Gillespie]

On Dec 26, 2024, at 6:20 PM, Simon McConnell <simonmc...@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.

Hey, I get the mantra. I've been around long enough in the OSS word to have contributed to apache before it was apache, and was a freebsd developer.

But let's be realistic, what you've described just isn't how it works.

For me to go figure out why a thing is happening in a new code base requires me to first get my head into that code base—possibly hour(s) or more depending on how good the other author(s) were writing it. I just don't have time to go figure out everybody's code.

What I'd like is a more code-automation friendly output (enabled with cmd line option). JSON stream maybe (line-delimited JSON).

I have a rule that there's zero warnings in my team's codebase, but to enforce that with the way it works now is a royal nightmare to script, and still exclude the deps.

So instead, we have a wrapper around all of the output to detect warnings as part of our CI process, and separately which wraps and cleans up the output of coveralls. I prefer very tight and clean output that tells the developer exactly what they need to know (and only that—coveralls is too great an infodump). 

The problem here is that one has to consider the purpose of the output during compile, and it's not just a simple single-purpose thing:

1. progress?
2. notification report of problems in your code (what 99.999% of all the devs care about)
3. notification report of all problems everywhere
4. notification report of problems in deps?

The challenge here is that the output is trying to be all of these at once, and you get a less than optimal output for each when you mash them together.

To really get wild with it, what about an option for each? :D

-Brandon Gillespie

[Zachary Daniel]

FWIW this is all I’m going to need I think :)

On Dec 26, 2024, at 7:37 PM, Zachary Daniel <zachary....@gmail.com> wrote:



[Zach Daniel]

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....@gmail.com> wrote:

FWIW this is all I’m going to need I think :)

[Zach Daniel]

Yeah, this definitely puts a damper on my process. I can use `Mix.shell()` to correctly hide the output from everything *but* the warnings when using `Mix.Task.run`. This seems pretty inconsistent. It's actually better for me not to suppress any of it at all because otherwise the warnings just pop out of nowhere. I can't have a loading spinner or anything w/o it getting interrupted by the warnings for example.

Given that igniter as a tool's entire purpose is to fetch, compile dependencies, and then call code from them, this does put a pretty big hamper on my options in this regard.