Deprecation warnings [WAS Re: Testing Quicklisp with ASDF]

Robert Goldman rpgoldman at
Wed May 31 14:49:20 UTC 2017

On 5/31/17 May 31 -9:28 AM, Faré wrote:
> Why? Because the function has been deprecated for many many years. The
> only reason it hasn't signaled a style-warning before is because ASDF
> lacked the infrastructure to do so.
> When? Is a better question. Now that ASDF does have this deprecation
> infrastructure (since 3.2.0 in last January), is it a good time, less
> than 6 months later and without massive adoption of 3.2.0, to ramp up
> from style-warning to full warning? Maybe not. I'm thinking that the
> full warning may be usefully pushed back a few more months.

Suggestion: can we make an ASDF-specific subclass of STYLE-WARNING so
that programmers have the option of catching it and handling it?

Here's why I ask:  at our company, we routinely have Jenkins jobs where
we fail on even style-warnings (otherwise people got sloppy and left
them around, leading to real bugs not being caught).  Now we simply have
a zero-tolerance policy.

If one has to use a library that uses deprecated ASDF functions while
it's being fixed, it would be nice to be able to muffle just such
warnings, instead of having no option but to pull out the big club and
muffle all style warnings.


> -#f
> On Sun, May 28, 2017, 17:54 Anton Vodonosov <avodonosov at
> <mailto:avodonosov at>> wrote:
>     27.05.2017, 02:06, "Faré" <fahree at <mailto:fahree at>>:
>>      ASDF 3.3.0 has failures:
>>     Thanks. Interesting.
>>     A whole lot of failures seem to be related to using now-deprecated
>>     functions, that since 3.2.0 where causing ASDF to issue a
>>     STYLE-WARNING, but with 3.3.0 are causing it to issue a full WARNING.
>>     I'll send patches.
>     Fare, why do you want to fail compilation with WARNING
>     (
>     Best regards,
>     - Anton

More information about the asdf-devel mailing list