Use the current python interpreter for bootstrapping pip+venv

[linsword13]

Instead of hard-coding a list of paths, which is fragile and subject to
change. (For instance
#555.)

Also separate out the logic for getting the bootstrap python, and only
get it before use (instead of at init time.) This is to prep for more
complicated package manager flow (say spack+pip.)

[douglasjacobsen]

When we want to chain spack and pip as package managers, (i.e. spack_pip) do you envision that we would point bs_python at the spack installed python? And if so, do you think it's useful to have an interface to manipulate this, or should we just directly set it?

[douglasjacobsen]

And maybe building off of that, how do you see this behaving when bs_python changes during the execution of other package managers? (i.e. it's not known at init type)

[linsword13]

When we want to chain spack and pip as package managers, (i.e. spack_pip) do you envision that we would point bs_python at the spack installed python? And if so, do you think it's useful to have an interface to manipulate this, or should we just directly set it?

That's a great question (that I don't have a good immediate answer for.) I feel like I prefer the former (possibly via a directive.) Perhaps something analogous to how define_compiler works, and then the pip manager code will look for using the specified python. Need to hash out more details (like whether individual software_spec can use different pythons, and how to express the dependency of needing a spack environment first, etc.) though.

I am not sure I fully grasp your second question, do you have a rough example in mind?