diff options
author | QuellynSnead <quellyn@lanl.gov> | 2023-05-16 02:00:01 -0600 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-05-16 10:00:01 +0200 |
commit | c47b554fa1fbbd4f4272a0c197d3f68d32c079b9 (patch) | |
tree | be52985b55a4fb43e5fd3d8f29aefe35877249e9 /bin | |
parent | b027f64a7f175b0e7a18388d0aa2484599efd12d (diff) | |
download | spack-c47b554fa1fbbd4f4272a0c197d3f68d32c079b9.tar.gz spack-c47b554fa1fbbd4f4272a0c197d3f68d32c079b9.tar.bz2 spack-c47b554fa1fbbd4f4272a0c197d3f68d32c079b9.tar.xz spack-c47b554fa1fbbd4f4272a0c197d3f68d32c079b9.zip |
libxcb/xcb-proto: Enable internal Python dependency (#37575)
In the past, Spack did not allow two different versions of the
same package within a DAG. That led to difficulties with packages
that still required Python 2 while other packages had already
switched to Python 3.
The libxcb and xcb-proto packages did not have Python 3 support
for a time. To get around this issue, Spack maintainers disabled
their dependency on an internal (i.e., Spack-provided) Python
(see #4145),forcing these packages to look for a system-provided
Python (see #7646).
This has worked for us all right, but with the arrival of our most
recent platform we seem to be missing the critical xcbgen Python
module on the system. Since most software has largely moved on to
Python 3 now, let's re-enable internal Spack dependencies for the
libxcb and xcb-proto packages.
Diffstat (limited to 'bin')
0 files changed, 0 insertions, 0 deletions