search

bskinn / stdio-mgr

Context manager for mocking/wrapping stdin/stdout/stderr
MIT License
14 stars 4 forks source link

Remove declared Python 3.4 support #40

Closed bskinn closed 5 years ago

bskinn commented 5 years ago

The major version bump should be a fine time to do this.

bskinn commented 5 years ago

Plan to leave the Python version constraint such that v2.0 will allow installation on 3.4, and to leave 3.4 in the tox matrix as long as pytest & other tooling allows.

As soon as testing on 3.4 is no longer practical, or code changes lead to observable 3.4 incompatibility, will need to update python_requires to strictly forbid installation there, prior to pushing a new release to PyPI.

jayvdb commented 5 years ago

I would appreciate keeping Python 3.4 support as long as possible.

The lack of a py27 backport (https://github.com/bskinn/stdio-mgr/issues/34) already causes problems with adoption by tools like seen at https://github.com/kvas-it/pytest-console-scripts/issues/24 . I would hate to loose more potential uses because of py34 being dropped. It was the stable v3 release for a very very long time.

I am hoping to also use this for @coala , which still supports Python 3.4, likely until we push out a much delayed release. I'll be happy to assist if Python 3.4 is causing any troubles.

I am quite sure we will find some features not possible with 3.4. https://github.com/bskinn/stdio-mgr/pull/53 even has problems with Python 3.5.

bskinn commented 5 years ago

Nah, I'm good to keep 3.4 officially supported for v2.0...pytest and pip have started complaining about it but seem to work fine, still. Worst case we can just pin a couple of things in the development environment for this release.

I've been continuing to muse on a 2.7 backport...I'd really rather not muddy master with 2/3 compact, but a backport branch would be fine. I figure it's an open question what of the new 2.0 functionality is actually practical in 2.7...though maybe more of it is than I think?

bskinn commented 5 years ago

Mmmm...but a separate backport branch makes bringing any new features back to py2 require 2x the effort, always...whereas 2/3 compat on master would be a lot easier.

I guess if there will be a stairstep of supported features along 3.4/3.5/3.6...what harm in tagging 2.7 on the bottom rung?