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

Sunsetting Python 2 support #164

Closed
banesullivan opened this issue Apr 15, 2019 · 11 comments

Comments

@banesullivan
Copy link
Member

commented Apr 15, 2019

We should set a timeline for dropping Python 2 support per https://python3statement.org

We barely test vtki on Python 2 and outright do not support Python 2 on Windows - setting a timeline for officially not supporting Python 2 on all OS would help clean up some code and build scripts.

This might have implications for the conda and PyPI deployments - is there a way we could let those vendors know not to allow installing vtki on Python 2?

@akaszynski

This comment has been minimized.

Copy link
Member

commented Apr 15, 2019

Looking at the web page, there's two ways we can do this. Like most of the projects, we can just drop support outright (either now or on 1 Jan 2020), or we can keep an older version of vtki around with LTS.

I'm leaning towards just dropping support outright. I have some dependent projects that are still barely Py2.7 compatible and I'd really like the companies using them to abandon 2.7 altogether. Having vtki supporting 2.7 would make that easier. Plus, I'm tired of writing extra hooks or tests for Py2.7.

As for PyPi and conda, we can simply add in the following in setup.py (idea from stackoverflow)

import sys
if sys.version_info.major < 3:
    raise RuntimeError('Only Python 3.4+ supported.  ' + 
                       'Please install a modern version of Python')

or (preferred)

setup(
    ...,
    python_requires=">=3.3"
)

That will stop anyone from trying to install using an unsupported version of Python outright. As far as I know, the conda installer can specify which version of Python a package is allowed to be installed on; whoever's maintaining that will have to change the allowed Python versions. PyPi

@banesullivan

This comment has been minimized.

Copy link
Member Author

commented Apr 15, 2019

I'm leaning towards just dropping support outright.

Me too - it's become quite an annoyance to write hooks and debug 2.7 errors.

Also, thanks for looking into ways to enforce a Python 3 install! I'll handle all of the anaconda stuff when we decide to move forward with this.

I have some dependent projects that are still barely Py2.7 compatible and I'd really like the companies using them to abandon 2.7 altogether.

I too have PVGeo still supporting 2.7 as ParaView uses Python 2.7. Kitware has a plan in the works for switching to Python 3 but who knows when that will play out.

On the note of your other packages and mine still needed on Python 2.7, I think the core API of vtki is good enough for those packages at this point (v0.18.1) so perhaps just limit their dependency to v0.18.x whenever we decide to officially drop 2.7 support. This could be done through a hook in the setup.py that will limit the vtki dependency to v0.18.x on Python 2 but not limit the version on Python 3.

banesullivan added a commit that referenced this issue Apr 18, 2019

banesullivan added a commit that referenced this issue Apr 18, 2019

@banesullivan

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2019

Note that I have disabled testing for Python 2.7 on Travis in #176

I'm tired of dealing with Python 2 issues... and we barely tested the library on 2.7

If we need to add this back, we can set up build matrices with allowed failures. I started doing this a while back on the travis branch

@banesullivan

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2019

PVGeo will still run tests on Python 2.7 - I'll keep an eye out there for Python 2 issues as at this point all that matters for 2.7 is that the core API (being access to VTK data structures, no plotting) works.

@akaszynski

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

I still have to test for Python2.7 as well, so between the two of us we’ll at least be able to catch most code breaking bugs.

banesullivan added a commit that referenced this issue Apr 19, 2019

@banesullivan

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2019

So at this stage, we are: "unofficially supporting Python 2.7"

@banesullivan

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2019

Note the new version specification in the setup.py from b016bf0

@akaszynski

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

Long live Python 3+!

@banesullivan banesullivan added this to the 0.18.3 milestone Apr 19, 2019

@banesullivan

This comment has been minimized.

Copy link
Member Author

commented Apr 20, 2019

The deployment testing scripts are now testing vtki's ability to be installed and render a single example on Python 2.7

See the scripts and Travis/AppVeyor badges on https://github.com/vtkiorg/vtki-deployment-test

@akaszynski

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

Think we can close this issue?

@banesullivan

This comment has been minimized.

Copy link
Member Author

commented Jun 8, 2019

Yes, let's close this. I think we should keep the issue pinned incase anyone starts to post an issue that might be 2.7 related for a bit longer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.