Drop support for Python 3.6

[bhrutledge]

Since Python 3.6 is EOL, we can reduce the time of our test suite and maybe use some new language features.

Would this qualify for a major release, e.g. 4.0.0?

In order for this to be merged, we'll need to remove 3.6 from the required checks for main.

[sigmavirus24]

Would this qualify for a major release, e.g. 4.0.0?

Yeah, it's not a breaking change in the scary way but this gives folks a way to cap their dependency if they rely on 3.6.

I think we might also consider integrating pre-commit and pyupgrade so we automagically get access to some newer features

[bhrutledge]

I think we might also consider integrating pre-commit and pyupgrade so we automagically get access to some newer features

@sigmavirus24 Can you elaborate on this, and/or link to a project with an example?

I've used pyupgrade on an ad-hoc basis before; I'm happy to run that on this PR to see what it does.

As for pre-commit, I really like the concept, but have found it tricky with editor integration, e.g. running flake8 and black on save. IIRC, there wasn't a streamlined way of keeping tool versions in sync between pre-commit and the virtual environment used by an editor. I also found the combination of pre-commit, tox, and CI hard to reason about.

[sigmavirus24]

@sigmavirus24 Can you elaborate on this, and/or link to a project with an example?

Flake8 uses it:

• https://github.com/PyCQA/flake8/blob/main/.pre-commit-config.yaml is the config
• https://github.com/PyCQA/flake8/blob/ddae449ceceb83bab3a273cad9554016cfacc41e/tox.ini#L54-L58 we allow folks to run it from tox if so desired
• we use pre-commit.ci which will also auto-fix people's PRs for them

github3.py also takes advantage of it and so does uritemplate

As for pre-commit, I really like the concept, but have found it tricky with editor integration, e.g. running flake8 and black on save. IIRC, there wasn't a streamlined way of keeping tool versions in sync between pre-commit and the virtual environment used by an editor. I also found the combination of pre-commit, tox, and CI hard to reason about.

I've not found it difficult, but perhaps you could elaborate on your difficulties.

[hugovk]

e.g. running flake8 and black on save.

There are some bits of Flake8 that are incompatible with Black, so it's important to configure Flake8 to play along. See:

• https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#flake8

[sigmavirus24]

e.g. running flake8 and black on save.

There are some bits of Flake8 that are incompatible with Black, so it's important to configure Flake8 to play along. See:

* https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#flake8

We already run black and flake8. This comment is unhelpful and reads like a robotic reply

[bhrutledge]

This avoids an error in the docs build:

WARNING: py:obj reference target not found: typing.AbstractContextManager

By taking advantage of PEP 585 via from __future__ import annotations (noting that typing.ContextManager is deprecated in Python 3.9). There's a lot more that could be done, e.g. replacing Dict with dict and Optional[str] with str | None, but I think that would be best handled in a separate PR.

[hugovk]

Sorry, I should have checked the source first.

More constructively (hopefully): I've also had good results with pre-commit, but it's important to run the lint tools via pre-commit (which pins them) rather than any system installed versions, which could be newer or older and format things differently.

I don't use these tools via an editor, but expect a similar problem could occur. If possible, I'd suggest hooking your editor up to run the pre-commit command instead (e.g. pre-commit run --files [filename] black instead of black [filename]) or else make sure you have the same version as pinned in the pre-commit config.

[bhrutledge]

I've removed the required check for Python 3.6. Merging this as-is, and will follow up with a pyupgrade PR.

As for pre-commit, I really like the concept, but have found it tricky with editor integration, e.g. running flake8 and black on save. IIRC, there wasn't a streamlined way of keeping tool versions in sync between pre-commit and the virtual environment used by an editor. I also found the combination of pre-commit, tox, and CI hard to reason about.

I've not found it difficult, but perhaps you could elaborate on your difficulties.

@sigmavirus24 Basically what @hugovk said:

it's important to run the lint tools via pre-commit (which pins them) rather than any system installed versions, which could be newer or older and format things differently. I don't use these tools via an editor, but expect a similar problem could occur. If possible, I'd suggest hooking your editor up to run the pre-commit command instead (e.g. pre-commit run --files [filename] black instead of black [filename]) or else make sure you have the same version as pinned in the pre-commit config.

I use VS Code, which is really smart about detecting a virtual environment, and using the tools installed therein to, for example, format andlint on save. I prefer that flow to running on commit, and it gives me the flexibility to run the tools directly on the command-line.

I've tried the suggested workaround, and it either didn't work, or was very clunky to configure. I also generally have a preference for using the native interface of tools, and standard installation methods (e.g. pip install). My understanding of pre-commit is that tools must be configured to support it, and are installed from git repos.

That said, I know a lot of people swear by pre-commit, so if someone feels strongly, I'm game to help them incorporate it into Twine.