For (way) more context see https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...
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
Common Lisp ASDF maintainer considers resignation
11–20 of 69 posts
Re: Common Lisp ASDF maintainer considers resignation
#12Re: Common Lisp ASDF maintainer considers resignation
#13Earlier quoted context omitted.
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?
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.
Re: Common Lisp ASDF maintainer considers resignation
#14For (way) more context see https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...
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.
Re: Common Lisp ASDF maintainer considers resignation
#15For (way) more context see https://gist.github.com/phoe/7d24bdb1f2be76a02fecba8cfecbef3...
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
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.
Re: Common Lisp ASDF maintainer considers resignation
#16Earlier quoted context omitted.
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?
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.
Re: Common Lisp ASDF maintainer considers resignation
#17Earlier quoted context omitted.
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…
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.
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.
Re: Common Lisp ASDF maintainer considers resignation
#18I learn a lot about diplomatic language from posts like that.
I wonder how much time it usually takes people to write those. For me, it takes a lot of time and revisions.
Re: Common Lisp ASDF maintainer considers resignation
#19Earlier quoted context omitted.
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…
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.
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...
Re: Common Lisp ASDF maintainer considers resignation
#20Earlier quoted context omitted.
So another Python 2 vs 3 situation?
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…
Is there any impending prospect of major CL implementations distributing asdf-devel by default?