I had an interesting conversation the other day with a professor from MIT who is researching software design. He did a case study on git and found that the most reliable way of determining whether or not a command is well named is by asking multiple users exactly what they think it does. If everyone gives a different answer, it isn't well designed.

I'm opening this issue for a candid discussion on whether or not our current Spack commands are aptly named and whether or not some of them should be merged. This will probably lead to many flame wars, so please treat each suggestion with constructive criticism. Even if you don't use some of these commands (I certainly don't), there are many users who do rely on them.

list vs find

Okay, this is by far the most controversial change I'm suggesting. But I just want to make it clear that people who are switching to Spack from other package managers will routinely mix up these commands.

In this case, every package manager uses a different command. For Homebrew, brew list lists installed packages, while brew search lists available packages. For dnf/yum, dnf list seems to be used for listing available and installed packages, while dnf search seems to be used for searching for specific packages. For Modules, module list lists loaded modules, while module avail lists available modules.

I'm not sure if there are better names we could use, or if they are fine as is. So I'm open to suggestions on this one.

module load vs spack load vs spack module load

Disclaimer: I don't use these commands

As someone who doesn't use these commands, I don't really know what the difference is between these three things. Personally, I plan on sticking with module load. I'm fine with having a special Spack command that accepts specs, but we should only have one.

clean vs purge

I mentioned this in #2942, but we should probably merge these commands. Thoughts on whether to call the command clean or purge? Or should spack clean with no argument clean all stages and spack purge be used to purge things like caches and databases? I actually like the latter idea more now that I think about it.

EDIT: These commands were merged in #4970.

config vs configure

Here we have two completely unrelated commands with similar names. It might be good to get rid of config and use spack compiler edit or spack external get do the same job (we are talking about adding a spack external command to add external packages in #2507).

diy vs setup

(did there used to be a spconfig command too?)

Disclaimer: I don't use these commands

These commands seem incredibly useful for developers, but based on the name alone I have no idea what the difference is. I was talking to Jim Amundson (@amundson?) the other day about a different developer command that he was working on (although not planning on contributing to Spack). I think @citibeth mentioned that there was some Spack Environments working group tasked with solving this problem, so I'll let them handle this.

test vs install --run-tests

I think users who want to test their installations will be confused that spack test doesn't do what they think it does. This is probably an issue for a later date since we have a lot of current work on this front and things will likely change.

md5 vs sha256 vs checksum

I think @citibeth has mentioned this before, but we should probably merge these commands.

EDIT: #6428 removed the md5 and sha256 commands.

doc vs docs

#3033 (currently) adds a spack docs command. There is already an existing spack doc command. As you can imagine, this is pretty confusing.

EDIT: doc was renamed pydoc.

aliases

Do we really need spack compiler list and spack compilers? Also, why are there so many aliases for the subcommands of spack view? Every subcommand has 2 or 3 aliases:

$ spack view --help
usage: spack view [-h] [-v] [-e EXCLUDE] [-d {true,false,yes,no}] ACTION ...

positional arguments:
  ACTION
    symlink (add, soft)
                        add package files to a filesystem view via symbolic
                        links
    hardlink (hard)     add packages files to a filesystem via via hard links
    remove (rm)         remove packages from a filesystem view
    statlink (status, check)
                        check status of packages in a filesystem view