Need help with package name


I’m working on a package that accomplishes two things, both related to enabling and disabling installed packages. This may be a waste of your time but I’d like some help naming it.

First it provides a list of your installed packages and each one can be toggled between enabled and disabled with a click on the name. Secondly it provides a built-in algorithm, similar to a git bisect, that enables a set of packages for each reload to find what package is causing an error.

I have been going crazy trying to figure out what to name the package. I have a history of some bad names, like tab-smart-sort (grin). I was hoping to find some short name that hints at both features. I would appreciate some suggestions. Here are some I’ve considered.

  • package-manager - This is too similar to package-manager-commands and it doesn’t hint at any features.

  • find-bad-package - Doesn’t hint to the select-enabled feature and seems to be saying a package is “bad” instead of just having an error.

  • find-guilty-package - My current bad name. Same missing feature and too cute.

  • package-bisect - Same missing feature but really gets to the point about bisect.

  • bisect-disable-packages or disable-and-bisect-packages - These cover all ground but are confusing. The second one is also long. I’ve always wondered why find-and-replace wasn’t just find-replace.

Comments would be appreciated …

Edit: I guess cute names like package-cop should also be considered.


It sounds like your package’s basic focus is on finding bad or slow packages and taking them out. And improved interface for toggling packages would be nice, but it doesn’t feel like the main course. The word ‘disect’ isn’t very clear if you don’t know it from git. Some ideas:


I think it might also be worth pondering splitting the package. One feature may be valuable without the other, and if it’s hard to find a simple descriptive name that might be a sign…


:+1: for package-triage or package-cop


You are right. The easy selection feature comes for free in the UI so I got carried away with it. I’ll give up on putting in a hint for the package toggling.

I had the same thought. The overall scheme demands the manual toggling feature but it doesn’t have to be “marketed”.

This package spec is evolving rapidly as I work on it. Some new features are complicating things even more …

  • It now serves a third purpose as a general purpose logger. It logs the test results over time and you don’t really have to be doing an “active” test to make use of it.

  • You can blindly enable whatever packages you want, do your normal workflow, and only have to deal with this utility when an error happens and you log the error. Then you can go back to work with little interruption…The log can later be processed by an inference logic engine.

  • Logging is also good for reporting. You can say bug foo happened the first time when package bar changed to version X. This “coincidence” checking is a different kind of analysis from bisection.

  • I’m going to monitor whether a package was activated when the error happened, not just if it was enabled. I may only consider activated package status for inclusion in the test data.

  • I’m going to consider every version of a package as a separate entity in the inference logic. I’m also including each version of Atom in the test data like package data. The Atom version is a very significant variable.

  • I’m allowing one to register and track multiple problems as they happen. This means the multiple problems can share test state and get more utility out of each reload.

  • I’ve also got some ideas that enhance the testing not just passively monitor it.

    • One trick is to force all packages to be activated at load. This will slow down load time and other operations but should increase the chances of breaking it which helps.

    • Some serious breakage can be done by using fuzz-busting. In other words randomly and rapidly fire off commands (being careful to protect stuff).

    • Fuzz busting would also be a good for acceptance testing of a single package.

All this mish-mash of features can be blended together into a new type of utility that is everything having to do with monitoring packages and their problems. In other words it does one thing but has a tool-belt of different tools.

So I am liking package-cop more and more. It also goes well with the existing time-cop. I wonder if there is a way I can reserve package-cop until my first release.

I appreciate the help @braver. And just spouting out this stuff helps me think. I hope I haven’t wasted other’s time.

And, comments are still welcome. Maybe I’m going too far with this?


Package-triage is also sounding better. Do we want to be a policeman or a doctor? I think maybe policeman makes more sense since we find the guilty packages, not fix them.

And again, package-cop goes well with the existing time-cop.


Cop also makes more sense because you’re adding monitoring and logging features.

Some variations on the theme:


What about package-blame?


Not bad. But I’ve decided to go with package-cop for better or worse. I’ve published the skeleton to claim the name.