I had no intention of debating importance of warnings or other language design decisions. I simply wanted to know how I can suppress warnings.
These threads can be a great resource to quickly answer specific questions. However now, someone else might wonder how to suppress a warning, but instead of quickly seeing a clear answer, they get to read through paragraphs of your opinions and ideas about warnings and other language design decisions. None of which really even attempt to answer my questions.
That “record” didn’t seem so obvious to me otherwise I wouldn’t have even posted this thread to begin with. And yeah I think so too that’s why I initially selected your answer as the solution.
Obviously, it is better to not have warnings than to have warnings and suppress them… Who would think otherwise… If I could flick a magic wand and instantly fix all the thousands of warnings I would.
Again… I’m not defending the suppression of warnings being “sloppy” or the quality of the code itself! I also want them fixed and think they should be fixed, but “should be fixed” is not an answer to my question. I have real problems to solve yesterday and spending the next month fixing warnings is not the main one. I can only chip away at them incrementally. Can you even comprehend what an intermediary step might look like? In real life, you can’t go from thousands of warnings to 0 warnings without taking time substantial time to do so.
I know very little developers that think this, myself included. Sometimes the time to deal with the warnings isn’t worth the time it takes, so you have to suck it up. Nobody likes warnings.
Totally agree. I didn’t want to muddy the waters any further by debating the other topic voiced in this thread, but yeah - in the real world of commercial software development, being able to switch off warnings, especially selectively from legacy code so you can still see warnings for any newly authored code, would be very handy in many scenarios.
Waters are pretty muddied and there is an accepted solution is the second answer, so I think this thread still serves the purpose for others to find the answer and read discussion if they still want to. You can’t really post something like this without these kind of answers, especially when the question was also outright asked early on “why explicitly restrict it?” and the answer is that there is almost no good reason to have any warnings in production. @phewitt did make it clear that the situation he’s in is not his fault, so the discussion could have wrapped up a little earlier probably, ha.
Is this true for Elixir? The very fact that this doesn’t come up very often hints that this isn’t a problem for most people. I could be wrong though. But Elixir’s warnings are incredibly easy to fix if you do them as you go. I don’t buy for a second that someone is working soooooo quickly that they don’t have time to remove an unused variable or or add some parens before they push (that is not directed at you, @phewitt). I was thinking about this more recently and I’ll double down on saying I think we’d be much better served if --warnings-as-errors was the default for MIX_ENV=prod mix compile and those who really know what they are doing can set that to false. We are where we are, though!
There is a third hacky way which is to move all offending modules into packages. Depending on how things are organized, though, this could be an even bigger headache. But if you have clear boundaries it’s an option. #2 is prob best, though.
I think you’re right that big smelly codebases happen less in Elixir than in other popular platforms. Probably in part due to the very warnings we’re talking about Perhaps you’re right that it’s just not a problem: I can imagine that if there were many voices calling for this then the core team might have accommodated them.
Yeah, and I mean in general Elixir is harder to write smelly code in than many other languages, immutability solves a really large number of problems inherently. I also think the bell curve of the sorts of programmers that Elixir attracts skews more towards the “interested in good practices / doing things properly” end of the spectrum.
I’d still rather errors were errors and warnings were warnings, but definitely would be nice to have a MIX_WARNINGS_AS_ERRORS env var, for any MIX_ENV
Maybe the name should be changed to “development affordances” As was pointed out earlier, Go doesn’t provide this option and it’s far bigger than Elixir. Often enough, I end up with unused vars while commenting stuff out during development and I would find it super obnoxious if I wasn’t able to run a test because I had one. But I also don’t think it’s worth catering to anyone shouting that it’s their god-given right to push an unused var to production. I’m thankful Elixir is flexible here though OP wouldn’t be in this predicament if it was as stringent as Go is! (Once again, I’m glad it’s not).
Yeah, I suppose I like tools to be as flexible as possible, even though sometimes that leaves the door open for people to do dumb things with them. I prefer to solve those sorts of problems at an organizational level, rather than with restrictive tools.
A thought occurred to me that may explain what’s going on here. If you do a mix deps.compile you’ll see warnings for third party packages. There’s not a lot that can be done about those warnings–they’re third party packages and most of us don’t want to make fixes to our copy of these packages because the next time we upgrade our fix will be gone. I get more than one or two warnings if I do this.
On the other hand, mix compile will not report warnings for third party assemblies–only warnings on our code.
Since the OP mentions thousands of files and thousands of warnings I’m guessing they’re doing mix compile but if they are also doing mix deps.compile as part of an automated build process (or something along those lines) turning it off might cut down the number of warnings displayed FWIW.
That’s only the case if the dependencies have been compiled before. Depending on the project and workflow that might not always be the case. E.g. at work we maintain a bunch of mix projects, many libraries, so almost all changes (and therefore switching between branches) changes dependencies and therefore their compiled status.
I guess then it would depend on how frequently one needs to switch sets of dependencies. The projects I’ve worked on have always tended to be conservative on adding and updating external packages.
Right, obviously. Anyway, yes, your main point is correct, if OP is explicitly running deps.compile then they’ll be seeing all their deps warnings because apparently that forces a compile even if the deps are already compiled.
Perhaps you’re right that it’s just not a problem: I can imagine that if there were many voices calling for this then the core team might have accommodated them.
As was pointed out earlier, Go doesn’t provide this option and it’s far bigger than Elixir. Often enough, I end up with unused vars while commenting stuff out during development and I would find it super obnoxious if I wasn’t able to run a test because I had one. But I also don’t think it’s worth catering to anyone shouting that it’s their god-given right to push an unused var to production. I’m thankful Elixir is flexible here though OP wouldn’t be in this predicament if it was as stringent as Go is! (Once again, I’m glad it’s not).
