diff options
author | Greg Becker <becker33@llnl.gov> | 2022-11-09 00:25:30 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2022-11-09 08:25:30 +0000 |
commit | 284c3a3fd8a4213a2cc6bf4aef85d672369f4b5b (patch) | |
tree | 04d73001576bc0b2b2a80a45bef5cfcdf578c7ff /bin/spack_pwsh.ps1 | |
parent | ec89c47aeee8b58bff7375158870ee13bfae9c64 (diff) | |
download | spack-284c3a3fd8a4213a2cc6bf4aef85d672369f4b5b.tar.gz spack-284c3a3fd8a4213a2cc6bf4aef85d672369f4b5b.tar.bz2 spack-284c3a3fd8a4213a2cc6bf4aef85d672369f4b5b.tar.xz spack-284c3a3fd8a4213a2cc6bf4aef85d672369f4b5b.zip |
ensure external PythonPackages have python deps (#33777)
Currently, external `PythonPackage`s cause install failures because the logic in `PythonPackage` assumes that it can ask for `spec["python"]`. Because we chop off externals' dependencies, an external Python extension may not have a `python` dependency.
This PR resolves the issue by guaranteeing that a `python` node is present in one of two ways:
1. If there is already a `python` node in the DAG, we wire the external up to it.
2. If there is no existing `python` node, we wire up a synthetic external `python` node, and we assume that it has the same prefix as the external.
The assumption in (2) isn't always valid, but it's better than leaving the user with a non-working `PythonPackage`.
The logic here is specific to `python`, but other types of extensions could take advantage of it. Packages need only define `update_external_dependencies(self)`, and this method will be called on externals after concretization. This likely needs to be fleshed out in the future so that any added nodes are included in concretization, but for now we only bolt on dependencies post-concretization.
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
Diffstat (limited to 'bin/spack_pwsh.ps1')
0 files changed, 0 insertions, 0 deletions