Hacker News Reader

Comment by ozten | Hacker News Reader

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

View on HN

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.

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.

Reply on news.ycombinator.com