Why not simply add these features to spack find?

@adamjstewart The two commands match arguments in different ways:

• spack find matches constraints on what is installed and accepts anonymous specs.
• this command accepts only non-anonymous specs and concretizes them the same way install does

Wouldn't it be confusing to have the functionality in the same command?

In the beginning I always got confused between spack list and spack find, maybe this is a reason to think about the general user interface again. Here you essentially say: There is a number of specs (most likely a "should be there"-list) and I want to see which of those are available and which need to be installed. Then there is spack list which gives you the packages that exist in spack, w/o regard to their installed status or concretisation and there is spack find which only operates on installed packages.

I'm not sure if this shouldn't all be done with one interface. I.e. only having a spack find that can either search the installed packages, the available packages, or concretise the input (as install would do) and then report the status of these specs.

Not sure if this should be done here, but this might serve as a starting point for this discussion

spack spec -Il or spack env <env> list -Ilr, in conjunction with grep, might also work.

I think a new name for the command (spack filter) to do the job is better than trying to add this functionality to the existing spack find. Also the output format appears to be tailored for scripting.

Wouldn't it be confusing to have the functionality in the same command?

👍

@alalazo anything prevents this PR from being merged? I would really like to use this nice feature, that is waiting to be merged since May 2018 ;-(

@adamjstewart @tgamblin could you guys review?

@davydden Another option that works for me would be to push forward #8612 and provide this command externally in another repo, if its use is foreseen not to be widespread enough to justify being in the main line.