Remove redundant Python 3.6 code

[hugovk]

Follow on from #9442 / #9437, remove some more redundant code for EOL Python 3.6, part two.

Sorry for the second PR, I missed some stuff in #9460: because feature branches aren't built on the CI, I usually temporarily remove the restriction, but this time did it in main and sent the PR from the old feature branch instead.

Relatedly, perhaps remove the feature branch restriction?

[nicoddemus]

Sorry for the second PR

No worries!

because feature branches aren't built on the CI

Hmm what you mean? Our configuration currently builds master and the maintenance branches:

pytest/.github/workflows/main.yml

Lines 3 to 7 in 325744e

	on:
	push:
	branches:
	- main
	- "[0-9]+.[0-9]+.x"

What do you mean by "feature branches"?

[RonnyPfannschmidt]

Thanks

[RonnyPfannschmidt]

@nicoddemus got 🥇

[hugovk]

because feature branches aren't built on the CI

Hmm what you mean? Our configuration currently builds master and the maintenance branches:

pytest/.github/workflows/main.yml

Lines 3 to 7 in 325744e

	on:
	push:
	branches:
	- main
	- "[0-9]+.[0-9]+.x"

What do you mean by "feature branches"?

I meant they're not built on my fork's CI.

An example:

Following the contribution guide, I checkout a new feature branch called your-bugfix-branch-name from main:

https://github.com/pytest-dev/pytest/blob/main/CONTRIBUTING.rst#long-version

$ git checkout -b your-bugfix-branch-name main
$ git commit -a -m "dummy commit, will the CI build this"
$ git push -u

Then, I can of course test locally, and usually do, but we have a powerful CI with a large matrix to test much more than I can (for example, lots of Python versions on multiple operating systems). It's usually quicker too, and has a nice clean env each time.

And to avoid noise I want to avoid opening a PR which then immediately fails the CI (I'm using a Mac and maybe missed something for Windows), so I check GitHub Actions on my own fork to address any failures first:

https://github.com/hugovk/pytest/actions

But oh, there's no build for the "dummy commit, will the CI build this" commit (hugovk@3c2c3f7).

Options:

• Just open a PR, cross fingers it passes, if not, iterate, and ping the dozens of watchers each time
• Make my changes on my main branch instead, not ideal as I only have one main; my main should be like upstream main and feature branches are the way to use Git
• Temporarily edit the config to enable feature branches for the CI (e.g. hugovk@c195c63 -> https://github.com/hugovk/pytest/actions/runs/1637790911 builds), iterate until ready to create PR, rebase out the temp commit, then create the PR

It would 's a nicer contribution path if feature branches are buildable on forks without any extra steps, and before opening PRs.

[bluetech]

@hugovk Will creating a PR first against your own fork's main work?

[hugovk]

Yes, it will: hugovk#6

Although I accidentally created it against upstream because GitHub defaults PRs there: #9463 (sorry!)

[nicoddemus]

Ahh got it, thanks.

Yeah not sure why we have that restriction in place TBH. I'm OK with removing and just building all branches.

Just open a PR, cross fingers it passes, if not, iterate, and ping the dozens of watchers each time

Having said the above, I think it is fine to open a Draft PR for that purpose: it conveys well that people are not supposed to be reviewing it just yet.

[hugovk]

PR created: #9467