@lee218llnl let me know if this works for you. would be great to get this, followed by #29317, so that we can move towards faster / immutable / atomic views everywhere (and simplify spack even more, since that does not require packages/spack to "undo" modifications to views per spec)

I found a few cases where this doesn't quite do what I want and have done prior to this PR. Consider this env:

# This is a Spack Environment file.
#
# It describes a set of packages to be installed, along with
# configuration settings.
spack:
  # add package specs to the `specs` list
  specs: [py-matplotlib, py-h5py, py-mpi4py, py-ipython, conduit+python, py-xdot]
  view:
    default:
      root: /usr/WS2/lee218/delete/spack-pr29336/var/spack/environments/python/view
      link_type: symlink
      link: run

The resulting bin directory in the view looks like this:

$ ls /usr/WS2/lee218/delete/spack-pr29336/var/spack/environments/python/view/bin/
2to3                       gdk-pixbuf-pixdata        pip3
2to3-3.9                   gdk-pixbuf-query-loaders  pip3.9
black                      gdk-pixbuf-thumbnailer    pydoc3
black-primer               gtk-builder-tool          pydoc3.9
blackd                     gtk-encode-symbolic-svg   pyftmerge
conduit_blueprint_verify   gtk-launch                pyftsubset
conduit_relay_entangle.py  gtk-query-immodules-3.0   pygmentize
conduit_relay_io_convert   gtk-query-settings        python
conduit_relay_io_ls        gtk-update-icon-cache     python-config
conduit_relay_node_viewer  gtk3-demo                 python3
conduit_staging            gtk3-demo-application     python3-config
conduit_staging.json       gtk3-icon-browser         python3.9
conduit_staging.sh         gtk3-widget-factory       python3.9-config
f2py                       idle3                     python3.9-gdb.py
f2py3                      idle3.9                   run_python_with_conduit.sh
f2py3.9                    ipython                   ttx
fonttools                  ipython3                  xdot
gdk-pixbuf-csource         pango-view

The gtk packages are dependences of py-xdot, but I do not want gtk in my view. In addition, we install the python binding for conduit in our python installation, but don't necessarily want conduit itself in the view. I realize that conduit is explicitly specified in my environment, so perhaps I will test to see if "exclude" will help in this case. Our use case here may not map perfectly to environment views, but I will see if it is close enough that I can put in a few workarounds like exclude.

Using exclude: [gtkplus, gdk-pixbuf] removes the symlinks for those packages and still allows py-xdot to work. However, and perhaps not a surprise, exclude: [conduit] completely excludes conduit, so I cannot import it when running python through the view.

Of course, in my ideal world ,there would be an equivalent to the way I currently activate packages in to my python installation, but I realize this may not warrant supporting if it's just us. If you were to leave it as is, I could exclude all the dependences and packages like conduit, and then for packages like conduit, I can manually link it in to my view.

I should also admit that in my current workflow with active, I take the list of "py-*" packages in my spack.yaml and create a shell script that does a spack activate py-blah, so either way, there is some manual tedium that I will have to go through.

@tgamblin do you have any advice on how to proceed? I guess I am OK with this PR as is, but if anyone has a suggestion on how to support our python use case directly in spack, I would appreciate it.

How did you handle conduit previously? Did it somehow only symlink part of the prefix, not the entire prefix?

Regarding py-xdot, I would not be surprised if it incorrectly specifies link-type dependencies as run-type dependencies.

Now that I look back at my notes, you may be right about conduit. It looks like I don't activate conduit, but rather symlink just the site-packages directory. That said there is no loss of functionality there. Sorry that I had forgotten this and thanks for the reminder.

if @lee218llnl has enough to do the deployment w/this PR then I think I'm happy with it. For some of the stuff above, we should probably revisit deptypes in dependencies as @haampie suggests.

I think I agree with @haampie that this is better than having something that only links in py-* extensions, since if those actually have a run dependency on something, it needs to be linked into the bin directory. Excluding link dependencies makes sense to me because we have RPATH to find them -- whereas we don't rewrite relative shebangs to point at install directories or anything like that. Maybe we should, but it wouldn't handle apps calling exec so I don't think it would be complete anyways.