mesa PR #10482 breaks packages requiring mesa and python@2

[baberlevi]

When #10482 was introduced, this seems to have broken the installation of any package which depends on a python2 version.

A few examples:
catalyst
grass

@codeandkey is working on a PR for eman2 that requires python2, and we can't quite figure out how to work around this.

It seems like python3 should only be a transient build dependency, but the spec won't allow both python2 as a run dependency and python3 as a build dependency to concretize together.

[baberlevi]

I guess this might get fixed by #4595

[scheibelp]

It sounds like this specifically affects packages which depend on mesa as well as python@2, so I will update the title.

codeandkey is working on a PR for eman2 that requires python2, and we can't quite figure out how to work around this.

In this case, does it specifically require mesa? Or does it depend on gl (which can be provided by registering an external for the opengl package, assuming you have a system libgl available).

It's also possible that this particular problem will slowly become less prevalent as Python 2 support is phased out (e.g. perhaps catalyst will start supporting Python 3).

See also: #11468

[baberlevi]

Yes, it specifically affects things that need py2 and mesa or mesa via gl.

Considering submitting a mesa-legacy package for the older versions which use the old build system as a work around.

[chuckatkins]

The issue isn't even mesa specific, that's just an instance of the spack bug of not being able to separate build and run deps during concretization. Basically this case:

A <-bld- B <-bld- py3
 \
   <-bld- py2

This is valid since py3 is a build only dep for B but currently both py2 and py3 ending up in the same dag, even though they don't need to be loaded at the same time, seems to generate an artificial conflict.

[chuckatkins]

The workaround for this has so far been to do a two stage install, i.e. first explicitly spack install mesa and then spack install the application. The second install seems to work since spack is only considering the runtime deps of an already installed package instead of also it's build deps.

[codeandkey]

I tried @chuckatkins' workaround and it seems as if spack is still trying to concretize build-only dependencies:

$ spack install -v mesa%gcc@7.3.0
==> mesa is already installed in /home/las_jtst/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/mesa-19.0.4-kav3sjdniowpike4asyjyxe36uy2cfps
$ spack install -v "eman2^python@2.7.16^mesa%gcc@7.3.0"
==> Error: An unsatisfiable version constraint has been detected for spec:

    python@2.7.16
        ^pkgconfig@0.9.0:


while trying to concretize the partial spec:

    mesa%gcc@7.3.0
        ^expat
        ^flex
            ^bison
                ^diffutils
                ^help2man
                    ^gettext@0.19:
                    ^perl
                        ^gdbm
                            ^readline
                                ^ncurses
                                    ^pkgconfig@0.9.0:
                ^m4@1.4.6:
        ^py-mako@0.8.0:
            ^py-markupsafe@0.9.2:
                ^py-setuptools
                    ^python@2.7.16


mesa requires python version 3:, but spec asked for 2.7.16

[chuckatkins]

@codeandkey the workaround seems to no longer work. I've just posted an issue documenting the bug that happens, #11542, which didn't used to be a problem.

[danlipsa]

Similar issue reported in: #11541

[chuckatkins]

@baberlevi #11595 just restored the older autotools build while keeping the package restructuring. Can you check that it resolves the issue for you please?

[scheibelp]

@baberlevi #11595 should resolve this issue so I'm closing this. Feel free to reopen if you can reproduce this with #11595.