# "Deleting" a package?

**URL:** <https://racket.discourse.group/t/deleting-a-package/1191>\
**Category:** Questions & Answers\
**Created:** [July 29, 2022, 2:27pm UTC](https://racket.discourse.group/t/deleting-a-package/1191 "2022-07-29T14:27:40Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\
**Post date:** [July 29, 2022, 2:27pm UTC](https://racket.discourse.group/t/deleting-a-package/1191/1 "2022-07-29T14:27:40Z")

</div>

[This recent discussion](https://racket.discourse.group/t/email-package-maintainers-when-their-packages-are-broken/1145/11) reminded me I have an old package [`echonest`](https://pkgs.racket-lang.org/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)`
- and of course the README explains the situation

Any other/better ideas?

---

<div class="post-metadata">

**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\
**Post date:** [July 31, 2022, 7:19am UTC](https://racket.discourse.group/t/deleting-a-package/1191/2 "2022-07-31T07:19:09Z")

</div>

> [@greghendershott](#):
>
> In other words the package is now forever useless.

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.)

> [@greghendershott](#):
>
> 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.

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.

> [@greghendershott](#):
>
> 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)`
> - and of course the README explains the situation

This seems fairly reasonable. Raising [`exn:fail:unsupported`](https://docs.racket-lang.org/reference/exns.html#%28def._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._exn~3afail~3aunsupported%29%29) 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.

> [@greghendershott](#):
>
> Any other/better ideas?

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.

---

<div class="post-metadata">

**Author:** ![soegaard](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/soegaard/32/19_2.png) [@soegaard](https://racket.discourse.group/u/soegaard)\
**Post date:** [July 31, 2022, 2:18pm UTC](https://racket.discourse.group/t/deleting-a-package/1191/3 "2022-07-31T14:18:40Z")

</div>

Apropos deleting packages:

> **[Stop Allowing deleting things from PyPI?](https://discuss.python.org/t/stop-allowing-deleting-things-from-pypi/17227)**
>
> BackgroundToday PyPI announced a plan to require the top 1% of packages will, in the future, require having 2FA enabled to interact with those projects, and as part of that announced it was giving away free hardware security tokens to eligible...