4 ms·

Warnings breaking builds is something you should opt in to with the knowledge that warnings are not part of the fixed public API of the thing you're building ag

Warnings breaking builds is something you should opt in to with the knowledge that warnings are not part of the fixed public API of the thing you're building against/using as a dependency. That's the whole point of warnings in the first place - they're a way to communicate that people might be doing something wrong, without hard failing their builds. Otherwise what would be the difference between a warning and an error? Likewise, opting in to warnings as failures in your build system is a perfectly reasonable decision if you want to be strict about quality, and catch potential issues early. But the fix for a warning you don't want to treat as a warning is to just suppress it somehow (or fix it anyway if it isn't a complete false positive), not demand the maintainer remove it. (Note I'm just replying to the context of your TLDR, not the whole situation, which I haven't read through yet.)

oalae5niMiel7qu 5y ago
The Quicklisp project repository (which is analogous to PyPI) requires that all projects included within it build without warnings. So treating warnings as errors isn't really opt-in in the CL community.
- etimmons 5y ago
  This is very misleading. Exhibit A: the warnings in question have been present for 5 years and the projects that end up triggering the warnings have not been removed. I don't know when QL started building with an ASDF version that produced the warning, but the absolute latest would have been Feb, 2021. The full story is that there is a sub class of warnings called style warnings. Any warning that is not a style warning is typically called a "full" warning. Full warnings do break compilation by default (the spec even mandates this). Style warnings do not. That is why ASDF typically starts the deprecation process with style warnings. However, the bad system name warnings do not happen during compilation. It roughly happens during configuration time (as ASDF is building its plan). Since this is not compilation, neither the spec nor QL care about the specific types of warnings produced. That's why the bad system name warning is a "full" warning.
- p1necone 5y ago
  That seems like a counterproductive decision on the part of Quicklisp. There's a reason that a distinction between warnings and errors exists, and making that decision across an entire package repository seems like a mistake to me.

oalae5niMiel7qu 5y ago

The Quicklisp project repository (which is analogous to PyPI) requires that all projects included within it build without warnings. So treating warnings as errors isn't really opt-in in the CL community.

etimmons 5y ago
This is very misleading. Exhibit A: the warnings in question have been present for 5 years and the projects that end up triggering the warnings have not been removed. I don't know when QL started building with an ASDF version that produced the warning, but the absolute latest would have been Feb, 2021. The full story is that there is a sub class of warnings called style warnings. Any warning that is not a style warning is typically called a "full" warning. Full warnings do break compilation by default (the spec even mandates this). Style warnings do not. That is why ASDF typically starts the deprecation process with style warnings. However, the bad system name warnings do not happen during compilation. It roughly happens during configuration time (as ASDF is building its plan). Since this is not compilation, neither the spec nor QL care about the specific types of warnings produced. That's why the bad system name warning is a "full" warning.
p1necone 5y ago
That seems like a counterproductive decision on the part of Quicklisp. There's a reason that a distinction between warnings and errors exists, and making that decision across an entire package repository seems like a mistake to me.