On Thu, 2017-10-12 at 13:03 -0500, Robert Goldman wrote:
That may be, but it was unfair to get angry at the ASDF maintainers about this. This is just a pre-existing error that was *manifested* because of a change in ASDF. It's not our fault that this error appeared, it's not our fault that the puri library is no longer maintained, and we can't be expected to avoid releasing improved versions of ASDF because there exists buggy, unmaintained code in Quicklisp.
No it's not your fault, but I think it would be a very sensitive idea to avoid annoying ASDF users, simply for practical reasons, because you'll find yourself with people who fork or refuse to update ASDF.
Something more useful would be to: * introduce the notion of ASDF compilation options, as a set of key- value pairs which control different compilation modes or effects * make the new strictness modes, like preserving the readtable, depend on those toggles, but upon introduction the default should be perfect backwards-compatibility, even if that is something you consider broken * blog about the fancy new way toggle and explain why it's better to use it than not * let the libraries' users nag the developers to change the code to be compatible with the new strictness checks * wait a couple of years (at least) until you see that most of Quicklisp libraries have been ported to the new way of doing things and if that happens maybe consider turning it on by default. In that case, announce it publicly * if adoption didn't happen, keep it disabled happily knowing that you can always turn it on in your company's internal projects.
This is more or less how we do things at work. It has a certain amount of overhead but it gains you good will from the community; on the other hand enabling things by default, and on a short notice, only makes you seem like you're imposing your preference on everybody else just for the sake of it. I think it's better to let things sink in and allow the users of ASDF to come to a consensus, although that's a slow process.