Drop support for Python 2.7 and Python 3.6 or older.

[labrys]

Description

This drops support for old python versions and will serve as a develop branch for a target release of 13.0.0 which will include changes that will break for earlier Python versions.

• Nightly progress should not be impeded by this PR.

• Nightly should be merged to Master when and if convenient and as often as necessary.

• Hotfixes for master/nightly should also be merged into this PR, although that may be easier said than done as I'm making a lot of changes.

• Users who have Python 2.7 and Python 3.7+ installed concurrently should be able to use the latest version since the user should be able to point a Python 2.7 app at the appropriate entry-point and the entry-point will run under the correct Python version.

• [ ] Migrated to a library that must be pip installed and will support updates through the --upgrade option for pip.

• [x] Use the python-requires option to prevent install on unsupported versions of Python.

• [x] Install all required dependencies without vendoring them.

• [ ] Define where the config files will live. Options include using an environment variable to point to config file, using standard system or user locations (e.g. /etc, windows registry, AppData, etc), using command line arguments for config file, etc.

• [ ] Provide entry-points as replacements for all the nzbTo* scripts.

• [ ] Create a hotfix-only maintenance branch for Python 2.7. It will maintain version numbers less than the first release to drop support (as of now expected to be 13.0.0).

• [ ] Shunt users stuck with Python 2.7 to the 2.7 maintenance branch.

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Test Configuration:

Checklist:

• [x] I have based this change on the nightly branch
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes

[labrys]

@clinton-hall This is the basis of a future v13.0.0 that will drop Python 2.7 and Python 3.6 and earlier. I will be merging branches into it in order not to affect nightly until such time as this version is ready to go live.

[clinton-hall]

what is the plan for this merge? Do I need to push nightly through to master first and then create a final Py2 release/fork? is there anything in place to prevent any Py2 system from updating beyond that release? i.e. should we push an update into master that then stops py2 systems from updating? or just force all existing Py2 users onto a new fork (so bug fixes can still be pushed?

[labrys]

1. Nightly progress should not be impeded by this PR.
2. Nightly should be merged to Master when and if convenient and as often as necessary.
3. Hotfixes for master/nightly should also be merged into this PR, although that may be easier said than done as I'm making a lot of changes.
4. This package will be migrated to a library that must be pip installed and will support updates through the --upgrade option for pip.
5. A library installation will use the python-requires option to prevent install on unsupported versions of Python.
6. A library installation will install all required dependencies without vendoring them.
7. A library installation will require a new way to define where the config files will live. Options include using an environment variable to point to config file, using standard system or user locations (e.g. /etc, windows registry, AppData, etc), using command line arguments for config file, etc.
8. Entry-points will be provided as replacements for all the nzbTo* scripts.
9. Users who have Python 2.7 and Python 3.7+ installed concurrently should be able to use the latest version since the user should be able to point a Python 2.7 app at the appropriate entry-point and the entry-point will run under the correct Python version.
10. A hotfix-only maintenance branch should be created for Python 2.7. It will maintain version numbers less than the first release to drop support (as of now expected to be 13.0.0).
11. Users stuck with Python 2.7 should be shunted to the maintenance branch.

[clinton-hall]

@labrys So the good thing with opensource is that everything is public and your name is clearly on all the great development going on here.... I am aware that your contribution to this project (along with that of some other contributors) far exceeds my personal abilities.... so is it time to actually move this to a "project" site as opposed to be being solely under my name? Do you know the process that would be required to set this up as a project and what are the pros/cons of doing so?

[labrys]

@clinton-hall Sorry for the delay in responding. I had to think about this for a while and never quite got the time to write up all my thoughts. I think I'd like to create a separate issue to discuss this so I can just post individual points as I think of them instead of writing them all in a single post. If you decide to migrate, the migration to a an organization on github is pretty easy. You just go to settings -> danger zone -> transfer to transfer it to an organization repository.

[clinton-hall]

I have removed Py 27 - 3.7 and added 3.11 - 3.13 via other commits. This has now added conflicts with this branch, but there is a lot more that was tidied up here that I still haven't got around to looking into.

I am going to close this PR now, but hoping to look into the other improvements at some time.