Make twine Python 3 only #437
Conversation
Codecov Report
@@ Coverage Diff @@
## master #437 +/- ##
=========================================
- Coverage 84.91% 84.3% -0.62%
=========================================
Files 14 14
Lines 809 771 -38
Branches 121 118 -3
=========================================
- Hits 687 650 -37
Misses 84 84
+ Partials 38 37 -1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
In general this looks good. It does conflate some stylistic changes with meaningful changes, and on the whole the changes look preferable. The changes could have been more conservative and still achieve the goal, but I'm largely in favor of the request. I've made some select comments for your consideration, but none are hard blockers.
|
Aha. And now I see that in #436, you've done just as I'd have - added the Python 2 compatible changes first. |
|
Thanks very much for the review @jaraco! I have rebased on the latest master so this PR no longer includes Python 2 style changes and extracted the |
|
I want to hold off on this until we can cut a 2.0 and I want to cut a different release today |
|
I have rebased to resolve merge conflicts. I also adjusted the tox environment "release" with
Sounds good to me. |
|
I'm ready to accept this. @theacodes do you have any objections? |
|
Isn't py3.4 EOL? Should we raise the minimum supported version to 3.5 or 3.6? |
|
Yeah, I agree. I've removed Python 3.4 support in the latest revision. |
|
I'm working on type annotations for #231. If twine required 3.6+, we could use the new syntax for variable annotations, instead of type comments. I don't know what other considerations there might be for dropping 3.5. |
|
No objections
…On Tue, Jun 11, 2019, 6:06 PM Brian Rutledge ***@***.***> wrote:
I'm working on type annotations for #231
<#231>. If twine required 3.6+, we
could use the new syntax for variable annotations
<https://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html#variables>,
instead of type comments. I don't know what other considerations there
might be for dropping 3.5.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#437?email_source=notifications&email_token=AAB5I434VEMD3QTLDNOZDODP2BDYVA5CNFSM4GJG4CDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXO6CFI#issuecomment-501080341>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAB5I43KBYVCZQE4JEQKWJTP2BDYVANCNFSM4GJG4CDA>
.
|
The twine project is moving to Python 3 only. As twine is a command-line tool, it is in a good position to move to Python 3 only. Other command-line-only tools have begun moving to Python 3. For example: black, mypy, pylint, pypinfo, and Sphinx. The twine command will continue to support uploading Python 2 projects to PyPI. So this should be mostly transparent to users. Allows for code cleanups. By removing these workarounds, the project will be easier to maintain and reduce ongoing testing resources. Python 2 is scheduled to be EOL on January 1, 2020. https://www.python.org/dev/peps/pep-0373/ For an overview of projects that have dropped Python 2 support entirely, see: https://hugovk.github.io/drop-python/2.7/
|
I have added a commit to remove Python 3.5 support. |
Allows dropping dependency on pyblake2, as it is now available in hashlib. Allows using f-strings instead of simple string formatting. Allows for future use of type hinting. PyPy3 is Python 3.5, so that support has been removed as well.
|
@jaraco Any more thoughts about merging this? Among other things, it'd be nice to use as a baseline for adding type annotations. |
|
@pypa/twine-maintainers How do y'all feel about merging this? It makes Twine require Python 3.6+, and drops support for PyPy. |
|
@sigmavirus24 said above:
I agree that this belongs in a 2.x release, and I think we should continue merging and releasing 1.x until the EOL, so at the earliest I'd support merging & releasing this on Jan 1, 2020. |
|
My preference would be to merge this and cut a release, but maintain a 1.x branch for bug fixes or other contributions deemed worthy of the effort. |
|
Right. I think at that time there was a "We'd like to rush something out" release and now is a perfectly fine time to release 2.x. We can branch a 1.x branch as @jaraco says and backport to that until Jan 1, 2020 as necessary. |
|
I was actually hoping to roll this out today, but it's blocked on #468. |
|
I've created a |
I would humbly like to suggest the twine project move to be Python 3 only. As twine is a command-line tool, it is in a good position to move to Python 3 only. Other command-line-only tools have begun moving to Python 3. For example: black, mypy, pylint, pypinfo, and Sphinx. The twine command will continue to support uploading Python 2 projects to PyPI. So this should be mostly transparent to users.
Allows for code cleanups. By removing these workarounds, the project will be easier to maintain and reduce ongoing testing resources.
Python 2 is scheduled to be EOL on January 1, 2020.
https://www.python.org/dev/peps/pep-0373/
For an overview of projects that have dropped Python 2 support entirely, see:
https://hugovk.github.io/drop-python/2.7/