search

MolSSI / cookiecutter-cms

Python-centric Cookiecutter for Molecular Computational Chemistry Packages
MIT License
384 stars 89 forks source link

Drop support for python 2.7 #18

Closed jchodera closed 6 years ago

jchodera commented 6 years ago

I see the .travis.yml includes support for testing with python 2.7.

No new projects should include support for python 2.7, and since this cookiecutter is intended to be used for new projects, we should drop this branch.

Lnaden commented 6 years ago

I'm okay with this, but since this is meant to be more generally helpful and Python 2.7 is technically still supported through Q1 2020, I kept it in initially.

jchodera commented 6 years ago

I think the spirit of the Python 3 Statement is that new projects would only use Python 3.x, while old projects can continue to support Python 2.7 bugfix releases for legacy code up to whichever date they choose prior to Q1 2020.

dgasmith commented 6 years ago

Python 2 is still the default version available on most OS's especially those that are not kept perfectly up to date for compatibility reasons or choose LTS support (supercomputers, local clusters, etc). Making this decision will say the following: 1 ) You will require some users to install their own Python (hopefully through a manager) 2) Any current Py2 only project in your ecosystem will need to be moved forward to Py3 effectively now (as in 3-6 months, not the next 18 months). 3) It would be good to choose a minimum Python3 version. I would say 3.5 at minimum 3.6 would be preferable.

I am huge fan of Py3 (especially for servers!), but I likely will not be doing too much of the work for point 2!

jchodera commented 6 years ago

1) We encourage all users to install anaconda python, since that's how we distribute our tools 2) omnia has already made that decision long ago 3) We support the last two Python releases (currently 3.5 and 3.6)

dgasmith commented 6 years ago

Ok, sounds good to me. Always good to check.

Py3.7 should be out around June. How do you handle sliding release windows like that?

Lnaden commented 6 years ago

We try to say "We support the last two releases of Python" start supporting the new version along with the previous, then a while after stop releasing on the older one. I like having a buffer for both to give all other dependencies time to get their own cuts out.