I believe Spack has too many commands, poorly organized and of low quality. The typical user only needs a few commands; the rest are merely clutter. Some commands are of use only to a small number of Spack users, a small portion of the time --- for example, some of the spack edit commands.

We've gotten to this point by merging every command that came to somebody's mind at this point. To get anything better, we will need to apply some design and make some hard choices (and not necessarily make everbody happy). I believe we would do well to:

1. Review all commands and recommend a smaller, cleaner, more consistent set of commands moving forward.

2. Split the remaining commands into groups. Many existing commands are of no use to the average Spack user (i.e. not a Spack developer).

Further notes / rants below...

Why the opposition [to spack edit -b]?

Adding ever-more convenience commands gets away from the core mission of Spack.

I am concerned that Spack's UI is becoming bloated with large numbers (53) of commands of marginal value --- and that command line arguments to those commands are increasingly non-uniform; and therefore hard to guess/remember. At some point, it becomes easier for most people to just navigate through the directory hierarchy and edit the file themselves; than to use a special-built Spack command to edit package superclasses.

By "marginal value" I mean, go through this thought experiment: suppose Steve Jobs appears and demands that you remove 10 commands from Spack. Which commands will you remove while affecting Spack functionality as little as possible? Obviously not spack install. But quite possibly spack edit -b.

There's a point where less is more. And I believe we're past it. I looked through the commands, and found that I use / am aware of: config, diy, env, find, load, install, location, reindex, setup, spec, test, uninstall, module. I'm a "power user", and yet I use only 13 out of 53 Spack commands. And most of those 13, I have only used occasionally.

It's easy to find commands of questionable quality or marginal value. For example:

• A call to spack -h does not tell me the commands available. Why not? I had to guess/know to say spack commands.

• What does spack build do? A call to spack build -h does not tell me (I don't know why the description string is not printed out when we do -h). Meawhile, the description of the package cmd line arg. is misleading. (OK... looking at the description, I think this is wrongly named as well... spack build does NOT build a package).

• What is the difference between spack config and spack configure?

• I already have the md5 command, what does spack md5 buy me? Will it be easier to figure out how to use spack md5 to auto-downloand and compute a checksum, or just download it myself with curl and then run md5?