I think it's pretty ambiguous which default is better.

Iterating with spack edit x spack install x is more convenient with current defaults.

So is spack checksum --add-to-package x spack install x.

please add to #30634

I agree with @haampie, the usual development workflows are pretty annoying with reuse: True.

Moreover, this breaks the upgrade workflow:

$ spack install xyz
# Update Spack
$ spack mark -ai
$ spack install xyz
$ spack gc

With reuse: True, the second install will usually simply reuse the old version.

Ok given the lack of consensus, I'm proposing we move this to a more detailed discussion. I started one here:

• `spack install` and `spack upgrade` semantics #41882

The gist of it is that I think both consumer workflows and dev/upgrade/iterative workflows are important, so we should have command that serve them both. So I'm proposing to split some of this out to spack upgrade.

Please throw your thoughts over there.

@spackbot fix style

Let me see if I can fix that for you!

I was able to run spack style --fix for you!

==> Running style checks on spack
  selected: isort, black, flake8, mypy
==> Modified files
  lib/spack/spack/solver/asp.py
  lib/spack/spack/test/cmd/common/arguments.py
  lib/spack/spack/test/concretize.py
==> Running isort checks
  isort checks were clean
==> Running black checks
reformatted lib/spack/spack/test/concretize.py
All done! ✨ 🍰 ✨
1 file reformatted, 2 files left unchanged.
  black checks were clean
==> Running flake8 checks
  flake8 checks were clean
==> Running mypy checks
Success: no issues found in 610 source files
  mypy checks were clean
==> spack style checks were clean

I've updated the branch with style fixes.

@tgamblin finally tracked down all the tests that relied on the old behavior and fixed them.

Based on the conflicting view here, I think we should wait to merge this for an upgrade command, so please weigh in on the discussion. It seems like we're pretty close to a consensus over there -- there is a debate about how aggressive upgrade should be.

#41882

I changed my mind about this after #43190.

Build caches are much more useful, and the experience is more apt-get install ... like. But only if roots are reused.

I would say let's change this default for 0.22

With libc merged in #43190, and other improvements that make it possible to install specs without having their compiler configured locally, it makes more sense to have --reuse as a default. This would allow, for instance:

$ spack install gcc

to work without a compiler currently configured, if a binary is in a registered buildcache.

Since the consensus changed, I'm going to merge this one. Checked with @michaelkuhn in DM