Hacker News Reader

Comment by tgbugs | Hacker News Reader

For (way) more context see https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...

TLDR;

"Dev: Oh, you must have been using undocumented behavior of ASDF. Your code will continue to work as before, but if you change this #\- to a #\/ it'll stop complaining. User: Our code used to work in ASDF-stable. Any warning at all breaks our build, so it's broken in ASDF-devel. Just make it work like it did in ASDF-stable again. ... User: That undocumented behavior works well for us, though. Dev: That behavior that is a burden for us as ASDF maintainers, and we want to clean up our code and stop supporting it altogether."

Another TLDR would be;

ASDF-stable is good enough that there isn't an incentive to update to a version of ASDF-devel that breaks backward compatibility.

So another Python 2 vs 3 situation?

Seems somewhat less impactful than that, but analogous, yes.

Not quite. The analogy is present explicitly in the gist but the comparison isn't particularly useful for understanding the social dynamics of the situation here.

This seems like a very minor thing in comparison. The python 2 to 3 thing had many big issues. It was impossible to automatically convert code from 2 to 3. It was very complicated to write code that would be compatible with both versions. If one of your dependencies was 2-only, then you had no choice but to wait for them. Meanwhile, with most software being on 2, libaries were incentivized to stay on 2. So there was a chicken and egg issue.

Is there any impending prospect of major CL implementations distributing asdf-devel by default?

"asdf-devel" is just what this post is calling "releases newer than the ones implementations ship," which not only feels like an _incredibly_ slippery definition, but by definition, no, once an implementation starts shipping it it's no longer a -devel version.

I know of at least one distro that forcibly upgrades the ASDF that SBCL ships, though.

And distro behaviour is part of why the only reason anyone recently bothered working on lisp packaging for debian is the requirement for source packages for software shipped in main repo, so for one program someone built enough tooling to replace old debian tooling and build pgloader the way it should be done.

Well, the Python community is a few orders of magnitude larger than the Common Lisp community, so more of a tempest in a teapot situation here.

But isn't "breaking compatibility" here emitting a warning that the downstream is treating as an error (because they've chosen to treat warnings as errors)? I feel like emitting it as a warning doesn't break compatibility but the downstream complaining (sbcl?) happens to be high profile enough that they can raise a stink about it.

And specifically, a warning about using undocumented behavior.

Quicklisp doesn't include projects that build with warnings, so CL programmers are strongly incentivized to treat warnings as errors.

This is very misleading. See my other comment for more details: https://news.ycombinator.com/item?id=30052405

Well, I have to manually update SBCL's ASDF because otherwise package-local-nicknames aren't supported by uiop:define-package, and the new-uiop-loading needs to be done before my systems load for package-inferred-system to not choke...

You test against a devel version so that your users don't have to find out your software is broken the moment the devel is promoted to stable.

I run my tests against daily upstreams because I want to know something will break before my users find it out.

That TLDR worked for Python 2 for 10+ years after all.

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

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.

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.

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.

Is it really sane to have a world of software that can’t survive new compiler or loader warnings? That just seems crazy to me

Breaking over new warnings seems crazy, but that can be one of the prices of stability. C, Perl, JavaScript and others have similar problems and come to their own solutions.

(For instance, C has warnings under the -W flags and you could enable them all at compile time with -Wall, but then people depended on the specific flags under that option so there's also -Wextra now.)

Stability means sometimes you stay still when there are good reasons to move, though there's always a balance. Perhaps a larger solution is needed (more prevalent version pinning, or an ASDF 4.0), but this may be a tempest in a teapot. We'll see how this particular issue shakes out.

There is one school of software engineering which upgrades all warnings to be errors and thus fatal because "warning culture" leads complacency. Thus emitting a new warning as part of default behavior will break builds.

Yes. But if you do that, then you need to be willing to fix new warnings (or ignore them) when you update dependencies. After all, if an update adds a new warning about something dangerous you are doing in your code, but shouldn't be, wouldn't you like to know about it?

Running a red light is dangerous, therefore let's remove red lights..

You have it backward. This is installing a red light in the middle of a road where there is no intersection because 10 years from now there is a plan to build a crossroad and then wondering why people are angry about a traffic jam in the middle of nowhere. People who ignore warnings are the people who run new red lights and will eventually kill someone when the intersection goes in. The people who upgrade them to errors stop at red lights, don't kill anyone, and get rightfully pissed that someone put a red light up 10 years too early.

The people who upgrade warnings to errors are those who wire the check engine light to the brake. This is fine for a test environment where you want to highlight problems, but it does not mean you get to yell at whoever improved the check engine logic to detect more potential problems if you car now stops in the middle of the highway.

> That just seems crazy to me

its crazy, and supper harmful

sadly it's not that rare in e.g. C/C++ as far as I know

direct link to the tl;dr part: https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...

Thanks for that link. It is an overlong but has some interesting comments about Lisp culture, Hyrum's law, and backwards compatibility. "Don't break stuff" is valuable.

Reply on news.ycombinator.com