Hacker News Reader

Comment by tgbugs | Hacker News Reader

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.

View on HN

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

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.

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

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.

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

Reply on news.ycombinator.com