why does ASDF ask to please only define system/test?

Faré fahree at gmail.com
Wed Dec 12 04:18:38 UTC 2018

> old ASDF was a piece of software that wasn't
> designed for the tasks it is used for today (as in its API, let alone
> its implementation), and that was causing a lot of headache to "the
> users" you seem to be defending above.
Indeed, there has been a lot of mission creep in ASDF from ASDF 1 to
ASDF 3.3, some of it is explained in my 2013 article
http://fare.tunes.org/files/asdf3/asdf3-2014.html (search "Mission
Creep" in the article; obviously not covering improvements since, but
3.1 stabilized many ASDF3 APIs and introduced package-inferred-system,
while 3.2 had significant internal cleanups and enhancements including
for bundles plus major documentation update, and 3.3 introduces proper
support for staged builds).

> i don't have a strong opinion about this specific warning. to be
> honest, if i was the ASDF maintainer, it would be fine for me if the
> warning was off by default, and i would only turn it on in my own CI
> to send out the PR's and/or warnings to the relevant maintainers, and
> then let old and/or conservative libs continue to misbehave as they
> did with the old ASDF.
Actually, I believe the warning is here for a good reason and should
be there *by default*—to warn developers about their using a
misfeature that was never officially supported nor documented, caused
a lot of grief in the past, and has been deprecated for a long time
with a better, simpler replacement (typically, replace a dash by a
slash) that just works. I am glad that Robert agrees.

I also wouldn't be against introducing multiple levels of verbosity to
ASDF (though I'm not willing to do the job for free anymore). Ideally,
there would even be a way to get different verbosity levels for
systems depending on whether they are mere dependencies (where you'd
like to be able to disable all warnings after you pass QA) or software
you're developing. But doing this kind of things right would introduce
yet another backward-incompatible feature with an "interesting"
migration path, which would open its own can of worms and a lot of
time to be sunk in engineering, with no reward whatsoever to be
expected from the community.

I've done my share of sending patches to unresponsive or ungrateful
maintainers, warning people years ahead of an incompatible breakage,
etc. I've also done my share of breaking things, even when I did run
all the software through cl-test-grid. Mea culpa. [And, sure, we don't
have automated enough cross-platform CI. That would be a great feature
to add for a new maintainer.]

Anyway, I too am reminded why I chose to spend less time in the CL "community".
The Racket, Gerbil Scheme, OCaml and Nix communities are far from perfect,
but they are overall less dysfunctional, with less counterproductive
passive aggression—
oriented towards building new cool things that never existed before, rather than
religiously preserving as is the perfect code of our ancestors
(that never actually worked far beyond their obsolete use cases).
At this point my opinions on ASDF are for historical value only,
supposing a future maintainer wonders why the code is what it is
rather than worships it as perfect godly gift never to be changed.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"I'm not a procrastinator, I'm temporally challenged"

More information about the asdf-devel mailing list