This recent discussion reminded me I have an old package echonest that has failing tests -- and the tests can't ever pass again because the company no longer supplies that web API (IIRC Spotify bought them and shut down the API).
In other words the package is now forever useless.
Part of me would like to delete the package entirely, but even if the catalog permitted doing so, that seems like a bad idea in principle.
Should I update it one last time to some kind of "stub" package? For example:
all the provided functions just error
the package tests become just a one-liner like (check-true? #t)
It seems right in this case that the package really is useless. In the general case, I hope package authors think hard before reaching that conclusion: for instance, someone could have their own implementation of the API. (But that seems far-fetched for this particular API.)
I agree that deleting packages seems fraught with peril. In perhaps the worst-case scenario, in the NPM world, that sort of thing has created openings for supply-chain attacks.
This seems fairly reasonable. Raising exn:fail:unsupported might be particularly conscientious. I'd probably prefer just removing the tests to making them no-ops. Leaving the user to confront the underlying network error doesn't seem too bad, either.
Far more broadly, it would be nice to have a macro like define-deprecated that would cooperate with tooling to communicate with users more proactively than waiting for them to get an exn:fail:support. The macro implementation is probably just a matter of log-warning at compile time; the harder part would be figuring out what tooling would be useful.