@tgamblin

I think the general idea of using spack build-env is good. But I'd like to see it actually work for what spack setup does before removing spack setup.

I no longer use spack setup by itself; instead, I use environments in which one or more packages are marked "setup." This is a longstanding PR that has never been merged. Getting things merged into core Spack has become WAAAY too difficult. So instead, I just keep re-applying the PR whenever I upgrade Spack (which is only occasionally). These days, upgrading just the recipes I need is usually sufficient, core Spack isn't changing that much any more.

Although I do everything with Spack Environments, I have found them to be particularly ill-suited to what I do. Consider how we build a single package: write a recipe, run the recipe to get a built package, then spack load the package. Well, I would like to do the same thing for an environment: write the environment specification file (spack.yaml), build it, then run some kind of load procedure to make it live in my shell. (Ideally, generate a script that can make it live in the future, without the use of Spack). Instead of this, I get a system that tries to "automagically" creates and update views at every turn (wasting a lot of time doing so), that activates environments without me asking it to, that is hard to debug when adding single packages to a "concretize together" environment (which we are encouraged to use), and that has no built-in "setup / build-env" capabilities, even though "real life" environments involve some 3d party code and some self-compiled code (I've developed "spack harness" to address this in a realistic per-user manner). Usually I'm working against Spack Environment functionality, rather than with it. Recent changes have made the experience worse for me, not better.

Oh yes... and modules don't really work because they were never independently loadable / unloadable to begin with, at least not for things beyond basic stuff like a compiler or MPI library here and there. IMHO, only entire environments (which are known to be self-consistent) can be safely loaded / unloaded (or activated, or whatever we like to call it). Whether that is done by setting long paths in env vars, or by setting up views, is beside the point. Loading an environment by cobbling together 100 module files is particularly ill-suited to the task.

Spack does important essential things for me, but it doesn't quite do what I need, and I can't seem to keep up. I would like to see a version of Spack one. day that "just works," but the time investment to make that happen is more than I can afford at my job. I would love a re-think of Spack Environments (which could be put in side-by-side to how environments currently work), because the current incarnation is so far off-base from what I need.

In this context, removing spack setup is just one more thing that will make my life harder, even if there is a suitable replacement somewhere, at least in theory. Because overall, Spack doesn't do what I need in a well-thought-out manner. So tinkering with a featuer here or there will never make my life easier; but could easily make it harder.

Is there any way we could re-convene resources on thinking through "Spack Environments / Harness 2.0"?

@citibeth this PR is only about spack setup, it has nothing to do with Environments. If you would like to open a separate issue about Environments I can comment on some of your points.

Based on the number of open issues relating to spack setup, and the fact that you no longer use it yourself, I can't imagine anyone being negatively impacted by deprecating this feature. The feature will not go away until a future Spack release, but it will be deprecated to warn users that they will have to move to spack build-env in the near future.

@becker33 I'm not sure if spack build-env or spack dev-build is a better match. spack setup is kind of inbetween in the sense that it creates a script that can be run to setup the environment and build the package, but doesn't actually build the package. I'm fine with referencing either, just let me know what to change.

@adamjstewart I think spack dev-build -u cmake --drop-in is the closest equivalent to spack setup. It basically accomplishes the same thing as running the script that would've been created by spack setup.

I don't mind the deprecation, I guess, but I would like to point out that spack setup is important for me in everyday life as a developer.

When I first started using spack to support my development environment, I didn't realize that spack setup was the "old way" of doing what I wanted to do (build my development branch, including frequent rebuilds, while using dependencies provided by spack). When I realized I tried using spack dev-build, but it hasn't worked well as a replacement for me, and I've switched back.

The way I think about this is that spack dev-build is good for someone working on packaging their code, working out bugs in their package.py and build process. But it's not as good when the goal is to just work on the code itself, while not caring about packaging.

To me, the main shortcomings in the 2nd case of spack dev-build:

• Doesn't support multiple build directories. In fact, I'd like to put the build directory where I want it, and point the build to the location of the source tree. That's particularly needed on Summit right now, where the home filesystem on NFS is so unstable that most builds fail -- but I still like to keep my source where it doesn't get auto-purged.
• Having to source spack-build-env.txt, which screws up all kinds of other stuff (it makes make work, but actually even spack doesn't work anymore after having sourced it).
• spack setup gives me a spconfig.py which allows me to remember what options are set, and also let's me easily modify stuff without having to go back to add a new (maybe temporary) variant to the package.py and start things over. Even just changing compiler flags or build type (Release/Debug) is easily and quickly done as in a usual development workflow, ie, mostly forgetting about the fact that spack was used to setup the environment. (It'd be even nicer to me if it created a spconfig.sh rather than a spconfig.py, but that's not an actual issue).

The biggest drawback to spack setup are that it's been left behind and has some issues, though so far I've decided working around them is easier than using spack dev-build. Sometimes, the resulting executable is subtly different in stuff like rpath, that can be a bit of pain.

I realize that I could mostly do my development using spack environments. But I don't really like that this would mean duplicating what's already in my package.py into an environment, missing some stuff (like options/variants), and having them inevitably diverge over time.