@liamrpowell @adamjstewart @tgamblin @alalazo @scheibelp
Comments / discussion encouraged. We need to get this figured out, and we're running out of time.

Problem Summary

In just 7.5 months (2020-01-01), Python2 will be officially retired; and Spack currently lacks a coherent plan of how we will deal with this. At that point, a number of well-known Python libraries will require Python3. If Spack cannot easily install Python3 stacks out of the box by then, I believe we stand to lose users to systems that CAN do that (eg Anaconda); see #11396. I believe that January 1 2020 is the date that we should officially switch Spack to default to Python3.

The purpose of this thread is to come up with a roadmap on how to do so. The core problem is that, with the current concretizer, it is not possible to have packages support Python2 and Python3 in a totally transparent manner. For example, in py-mypackage.py we need to (but cannot use) statements such as:

depends_on('py-backported_stuff', when='^python@2')

General Solutions

This problem has prevented Spack from supporting Python3 in a "just works" manner, so far. There are two known solutions to it:

1. Successfully Concretize Python3-Based DAGs  #7926 uses a +python3 variant as a manual way for users to specify that Python3 is being used. This variant is applied to app packages (where applicable) using the all: functionality in packages.yaml. The above dependency can then be rewritten as:

depends_on('py-backported_stuff', when='~python3')

A user working in Python3 land can pretty much set-and-forget the all: +python3 directive in packages.yaml.

2. One might consider Successfully Concretize Python3-Based DAGs  #7926 to be a dirty "hack." A new concretizer that fixes these problem promises to be a more elegant long-term solution, allowing Python packages to specify dependencies directly.

So far, a long-term preference for (2) has prevented us from merging (1). However, I believe the time to wait for an improved concretizer is over: We need to be ready for an all-Python3 world by the end of this year. And currently, we are NOT EVEN CLOSE. Therefore, I believe we should formulate a plan along the lines of (1), using technology we already have. That will give us enough time to fix all the Python packages that need fixing, and to test them with Python3.

Python3 Transition Plan

This is a transition plan that I think makes sense.

1. Re-work Successfully Concretize Python3-Based DAGs  #7926 to use a python2 variant instead of python3. This makes sense because starting 2020, Python3 needs to be the default, in accordance with the rest of the Python community.

2. Review all Python packages for possible Python2-vs-3 issues; and code them in appropriately. Use the examples in Successfully Concretize Python3-Based DAGs  #7926 as a guide. Also see Default to Python 3.7 #10319.

3. Test that spack install py-xyz works for all Python packages. Test "out of the box" (Python3), and also with the all: +python2 variant enabled. We expect that some packages might not work for Python2 or Python3; and they should be updated appropriately. Sometimes a newer upstream version might be needed; in other cases, a package might really be Python2-only and be headed for the dustbin. Do this all on a branch that's periodically kept up-to-date with Spack's develop.

4. Fall 2019: Provide ABUNDANT notification to the Spack community that starting January 1 2020, Spack will go Python3 by default. Provide instructions on how to continue building Python2 stacks after that date.

5. Tag the last version of Spack BEFORE Python3 is made default; and notify users of that tag, if they wish to keep using it for a while (without re-doing their config to continue using Python2).

6. January 1 2020: Merge the branch into Spack's develop.

7. When the new concretizer comes out, remove the +python2 hack.

Alternate Plan

The above plan maintains backwards compatibility with Python2 systems. Alternately, we could decide that this is too much effort. In that case, the branch we prepare would only be tested for Python3, and the +python2 variant would not be needed. Python2-specific dependencies could simply be eliminated from Packages, making them simpler.

The alternate plan would be less work. But it would also mean that Spack users still using Python2 would no longer be able to upgrade to the latest Spack. My guess is, the additional effort to maintain backwards compatibility is probably worth it.