Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 2.7 deprecation timeline #1175

Closed
Anthchirp opened this issue Feb 28, 2020 · 10 comments
Closed

Python 2.7 deprecation timeline #1175

Anthchirp opened this issue Feb 28, 2020 · 10 comments

Comments

@Anthchirp
Copy link
Member

Anthchirp commented Feb 28, 2020

As we are all aware Python 2.7 is now well past its use-by date.
DIALS will need to continue supporting Python 2.7 for a while as we still rely on this for a number of reasons (DLS operations, CCP4 bundling, Phenix bundling, ...)

This ticket outlines my proposal how we can support this critical need without obstructing ongoing development effort.

Executive summary

On March 15 we will start the release branch for DIALS 2.2. DIALS 2.2 will support both Python 2.7 and 3.6. Like DIALS 1.14, this will be a long-term-supported (LTS) release, which means we will provide support and builds, initially until the end of the year. This may be extended if there is ongoing need for supported builds.

Meanwhile we will reduce the Python 2.7 compatibility in the master branch in a phased manner over a period of 6 months. This is to avoid a scenario where massive changes are introduced that then make it difficult to backport code to the 2.2 release branch.

Phase 1 -- 15th of March 2020

DIALS 2.2 branch date.

We stop officially providing or linking to any 2.7 nightly builds

We aim to keep Python 2.7 compatibility in dials, dxtbx, and xia2 master branches and refrain from any large-scale refactoring to not artifically make maintaining the 2.2 LTS release difficult. Python-3-only code is allowed in new files and where retaining Python 2 support is unreasonable or impossible (multiprocessing case). Where this causes tests to fail we will set up a "skip-this-test-on-python-2" fixture.

We will reduce the MacOS testing regime at Diamond to reduce the demand on our build machine.

Jenkins

  • Disable MacOS 2.7 builds for xia2
  • Disable MacOS 2.7 DIALS regression builds

Travis

  • no changes
repositorypython 3 allowed in...Python 2 testing coverage
dxtbxnew files and where Py2 support is unreasonable or impossibleEverything except newly excluded tests
dialsnew files and where Py2 support is unreasonable or impossibleLinux: Everything except excluded, MacOS: No regression tests
xia2new files and where Py2 support is unreasonable or impossibleLinux: Everything except excluded, MacOS: No test coverage

Phase 2A -- 15th of May 2020

This is 2 months after the initial 2.2 release.
The projected current release is approx. DIALS 2.2.4
This is the approximate branch date for DIALS 3.0.
Python 2.7.18 has been released.

This is an intermediate step where only xia2 is affected. DIALS and dxtbx master remain in Phase 1 for 6 more weeks.

We end all effort for Python 2.7 compatibility in xia2. Any large-scale refactoring, such as mass-removal of future/six statements, should take the need for backporting fixes into the 3.0 release branch into account.

With concurrent 2.2 and 3.0 release builds we will have increased demand on our build systems, so responses may be slower than usual.

Jenkins

  • Disable all 2.7 builds for xia2

Travis

  • Disable 2.7 flake8 checks for xia2
  • Disable 2.7 syntax checks for xia2
  • Disable all 2.7 builds for xia2
repositorypython 3 allowed in...Python 2 testing coverage
dxtbxnew files and where Py2 support is unreasonable or impossibleEverything except newly excluded tests
dialsnew files and where Py2 support is unreasonable or impossibleLinux: Everything except excluded, MacOS: No regression tests
xia2no restrictions, keeping 3.0 support in mindno test coverage

Phase 2B -- 30th of June 2020

This is 3.5 months after the initial 2.2 release.
The projected current releases are approx. DIALS 2.2.7 and DIALS 3.0.2

We still aim to keep Python 2.7 compatibility in DIALS and dxtbx master where possible. We aim to avoid large-scale refactoring, particularly in dxtbx. Python-3-only code is allowed where it provides a demonstrable benefit over 2.7-compatible code.

With concurrent 2.2 and 3.0 release builds we will have increased demand on our build systems. We now reduce the testing regime, in particular we end the long-running regression tests for DIALS.

Jenkins

  • Disable MacOS 2.7 DIALS builds
  • Disable all 2.7 DIALS regression builds
  • Disable MacOS 2.7 dxtbx regression builds

Travis

  • Disable 2.7 flake8 checks for dxtbx and DIALS
  • Disable 2.7 regression/slow tests for DIALS
repositorypython 3 allowed in...Python 2 testing coverage
dxtbxnew files and where there is demonstrable benefitLinux: Everything except excluded, MacOS: No regression tests
dialsnew files and where there is demonstrable benefitLinux: No regression tests, MacOS: No test coverage
xia2no restrictionsno test coverage

Phase 3 -- 15th of July 2020

This is 4 months after the initial 2.2 release.
The projected current releases are approx. DIALS 2.2.8 and 3.0.3

We still aim to keep Python 2.7 compatibility in dxtbx master. Python-3-only code is allowed where it would take additional effort to maintain Python 2.7-compatibility.

We stop all 2.7 testing on DIALS and remove all test fixtures. However we bear Python 2.7 compatibility in mind, and patches to maintain Python 2.7 compatibility are welcome.

Jenkins

  • Disable all 2.7 DIALS builds
  • Disable all 2.7 dxtbx regression builds
  • Disable MacOS 2.7 dxtbx builds

Travis

  • Disable 2.7 syntax checks for DIALS
  • Disable all 2.7 builds for DIALS
  • Disable 2.7 regression/slow tests for dxtbx
repositorypython 3 allowed in...Python 2 testing coverage
dxtbxwhere maintaining compatibility takes additional effortLinux: No regression tests, MacOS: No test coverage
dialswhere maintaining compatibility takes additional effortno test coverage
xia2no restrictionsno test coverage

Phase 4 -- 15th of September 2020

This is 6 months after the initial 2.2 release
The projected current releases are approx. DIALS 2.2.13 and 3.1.2

We end all Python 2.7 compatibility effort.

Jenkins

  • Disable all 2.7 dxtbx builds

Travis

  • Disable 2.7 syntax checks for dxtbx
  • Disable all 2.7 builds for dxtbx
repositorypython 3 allowed in...Python 2 testing coverage
dxtbxno restrictionsno test coverage
dialsno restrictionsno test coverage
xia2no restrictionsno test coverage
@graeme-winter
Copy link
Contributor

I have self-assigned this to take forward to PIs

Anthchirp added a commit that referenced this issue Mar 15, 2020
@Anthchirp Anthchirp pinned this issue Mar 16, 2020
@Anthchirp
Copy link
Member Author

As we are now in Phase 1 I've disabled Jenkins MacOS builds for xia2 and regression builds for DIALS as described. I have removed links to Python 2 nightly builds from https://dials.github.io/installation.html#development-builds

@Anthchirp
Copy link
Member Author

I have amended the timeline above following a request to delay Phase 2 until the end of June as to facilitate XFEL work.

Since this is independent of xia2 I have split up Phase 2 into 2A (remaining at original date but for xia2 only) and 2B (end of June, everything else).

Further, I've changed the wording to make clear that 'large scale refactoring' includes the removal of six/future statements. It also includes addition of type annotation, f-strings, and all other Python 3.6+ goodness.

@Anthchirp
Copy link
Member Author

Having just taken an inventory of all our Jenkins build configurations I would just like to make a note that we will also reduce the coverage of testing at Diamond on cctbx_project in line with the timeline above:

cctbx_python Python 2 test coverage at Diamond
from ... onwardsLinuxMacOS
Phase 1
(15th March)
libtbx, scitbx, cctbx, iotbx, rstbx with phenix_regression providedlibtbx, scitbx, cctbx, iotbx, rstbx
Phase 2a
(15th May)
libtbx, scitbx, cctbx, iotbx, rstbx with phenix_regression providedlibtbx, scitbx, cctbx, iotbx, rstbx
Phase 2b
(30th June)
libtbx, scitbx, cctbx, iotbx, rstbx with phenix_regression providedlibtbx, scitbx, cctbx, iotbx, rstbx
Phase 3
(15th July)
libtbx, scitbx, cctbx, iotbx, rstbxnot tested at Diamond
Phase 4
(15th September)
not tested at Diamondnot tested at Diamond

Python 3 test coverage of cctbx_project at Diamond will stay at the current level, which is libtbx, scitbx, cctbx, iotbx, rstbx without additional repositories present.

Obviously nothing changes in terms of code committed to cctbx_project as that is a separate project with its own rules. However we may not proactively identify cases where Python 2 incompatible code is committed accidentally.

Anthchirp added a commit that referenced this issue Apr 30, 2020
If a test fails on Python 2 and is expected to do so then mark it with
the 'python3' fixture.

If a test fails during the pytest discovery/collection phase due to a
SyntaxError in the test file, then add the filename to the exclusion
list in conftest.py. If the SyntaxError happens due to an import in the
test file then consider moving the import into the test function first.
Anthchirp added a commit to cctbx/dxtbx that referenced this issue May 14, 2020
Don't attempt to run Python 2 syntax/flake8 checks on newly added files.
See dials/dials#1175 for the deprecation plan.
@Anthchirp
Copy link
Member Author

We are now in Phase 2A, and I have disabled xia2 Jenkins builds accordingly. Whereas xia2 is now free to move on, the policy for dxtbx/dials remains at "Python 3 allowed in new files and where Python 2 support is unreasonable or impossible" until the end of June.

Anthchirp added a commit to xia2/xia2 that referenced this issue May 15, 2020
and make a warning more visible.

cf. #450 and dials/dials#1175
@dagewa
Copy link
Member

dagewa commented Jun 3, 2020

This proposal from the DIALS East group was agreed by representatives of DIALS West. It is only fair that this is made public here

We will not actively support Python 2.7 beyond the DIALS 2.2 long term support branch already discussed however we will also not remove six / futures / from future import lines for foreseeable future on the master branch. New code will be Python 3 only. There will be no large scale refactoring on master until such time as it becomes clear the existing approach is unsustainable.

We also offer to help to get Python 3 porting done, to get this done before Python 2.7 dependencies start to vanish - we concluded that these external forces would ultimately dominate the timescales for the move to Python 3 only.

Anthchirp added a commit that referenced this issue Jun 11, 2020
The check in the Azure pipeline is more powerful as it supports the
Github Checks API. Leave the Python2 flake8 check until we disable that
at the end of the month according to #1175.
Anthchirp added a commit that referenced this issue Jun 30, 2020
@Anthchirp
Copy link
Member Author

We are now in Phase 2B, and I have disabled the DIALS MacOS Python 2 Jenkins builds and the MacOS dxtbx regression builds accordingly. Travis no longer runs Python 2.7 flake8 checks and regression tests.

The policy for dxtbx/dials is now "Python-3-only code is allowed where it provides a demonstrable benefit over 2.7-compatible code." until mid-July.

@Anthchirp
Copy link
Member Author

We are now in Phase 3, and I have disabled the relevant Jenkins tests accordingly. Travis no longer runs Python 2.7 syntax checks and tests on DIALS. Test fixtures will be removed shortly.
We continue to run some basic testing on Jenkins for dxtbx with Python 2.7/Linux.

The policy for dxtbx/dials is now "Python-3-only code is allowed where it would take additional effort to maintain Python 2.7-compatibility". Although we no longer test on Python 2.7 any patches to retain 2.7-compatibility are welcome until mid-September.

Anthchirp added a commit that referenced this issue Jul 15, 2020
Warning is only shown on first import, and can be silenced in Python 2.7 with

import warnings
with warnings.catch_warnings():
    warnings.simplefilter("ignore")
    import dials

cf. #1175
@Anthchirp
Copy link
Member Author

I have disabled Python 2.7 syntax checking on cctbx/dxtbx on Jenkins due to cctbx/cctbx_project@9343e8a.

ndevenish added a commit to ndevenish/dials-fork that referenced this issue Sep 7, 2020
- Remove references to python 2/3 cross-compatibility in advance of
  completion of dials#1175
- Greatly soften the request for clean branch history in pull requests.
  Since we aim to squash-merge most pulls now, this is much less
  important because it mostly won't be seen on main branch.
- Pull requests should have `newsfragments` added to them
ndevenish added a commit to ndevenish/dials-fork that referenced this issue Sep 7, 2020
- Remove references to python 2/3 cross-compatibility in advance of
  completion of dials#1175
- Greatly soften the request for clean branch history in pull requests.
  Since we aim to squash-merge most pulls now, this is much less
  important because it mostly won't be seen on main branch.
- Pull requests should have `newsfragments` added to them
- Pre-commit is in many cases installed automatically now, so change the
  wording there.
- Be less wordy in flake8 section
ndevenish added a commit to ndevenish/dials-fork that referenced this issue Sep 7, 2020
- Remove references to python 2/3 cross-compatibility in advance of
  completion of dials#1175
- Greatly soften the request for clean branch history in pull requests.
  Since we aim to squash-merge most pulls now, this is much less
  important because it mostly won't be seen on main branch.
- Pull requests should have `newsfragments` added to them
- Pre-commit is in many cases installed automatically now, so change the
  wording there.
- Be less wordy in flake8 section
- Describe isort
ndevenish added a commit to ndevenish/dials-fork that referenced this issue Sep 7, 2020
- Remove references to python 2/3 cross-compatibility in advance of
  completion of dials#1175
- Greatly soften the request for clean branch history in pull requests.
  Since we aim to squash-merge most pulls now, this is much less
  important because it mostly won't be seen on main branch.
- Pull requests should have `newsfragments` added to them
- Pre-commit is in many cases installed automatically now, so change the
  wording there.
- Be less wordy in flake8 section
Anthchirp added a commit to cctbx/dxtbx that referenced this issue Sep 15, 2020
Anthchirp added a commit to cctbx/dxtbx that referenced this issue Sep 15, 2020
* Disable Python 2 testing (dials/dials#1175)
* Clean up Travis build scripts
* Retire Python 3 migration helpers
@Anthchirp
Copy link
Member Author

The 15th of September has finally arrived. It looks like the timeline was spot on, as some of the build job stages have started coming up with dependency package errors yesterday.

I have disabled all Jenkins Python 2 testing for cctbx and dxtbx, disabled the dxtbx travis testing, and removed associated code crutches. We can now move on.

@Anthchirp Anthchirp unpinned this issue Sep 15, 2020
ndevenish added a commit that referenced this issue Oct 1, 2020
- Remove references to python 2/3 cross-compatibility in advance of
  completion of #1175
- Greatly soften the request for clean branch history in pull requests.
  Since we aim to squash-merge most pulls now, this is much less
  important because it mostly won't be seen on main branch.
- Pull requests should have `newsfragments` added to them
- Pre-commit is in many cases installed automatically now, so change the
  wording there.
- Be less wordy in flake8 section

* Apply suggestions from code review

Co-authored-by: Markus Gerstel <2102431+Anthchirp@users.noreply.github.com>
Co-authored-by: David Waterman <dagewa@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants