Uh, is this something we're planning on doing for all the builders? I thought we created the globals so we wouldn't need all of this cruft.

There was a general consensus to get rid of std_{cmake,meson,pip}_args, because

1. they are defined in build_environment.py which is the wrong place:
   1. changes to their values is not reflected in the hash.
   2. they are defined for any package, whether they do depend on pip or not.
2. their origin is unclear when just looking at package.py

References to std_{cmake,meson}_args were already removed from other PRs.

I don't think PythonPipBuilder.std_args(self) is that much cruft?

The alternative is to leave the global, and define them in {cmake,meson,py-pip}/package.py
through setup_dependent_package(child, parent), but that is too broad as it should only ever
be called on a build edge <root spec to be built> - {cmake,meson,py-pip}, whereas right now
it's called on any in-edge of {cmake,meson,py-pip}.

Thanks, didn't know there was a discussion on this. As long as there is good reason (like the hash) and we're planning on doing the same for all build systems I'm happy.

FYI, the Packaging Guide still references std_cmake_args and may need to be updated with the new syntax.

To be fair, the package hash issue is not addressed by this PR because spack.build_systems.python is not hashed. The only improvements of this PR are:

1. remove dependencies on inputs from build_environment.py which are unaccounted for in the package hash.
2. allow users to find the definition of the default pip args global

Moving the literal value of std_pip_args into py-pip/package.py would fix the hash issue, but then the question is how to keep PythonPipBuilder.std_args in sync with it.

The similar PRs for std_cmake_args and std_meson_args were much smaller, so let me just bring up this PR in the Monday meeting.

@spackbot run pipeline

I've started that pipeline for you!