1. Thanks for letting me know.
2. requires-python is a runtime requirement. It determines version of python to run the code from a package. If we raise it it'd be misinformation, in that case users of 3.6 still would be able to run the prebuilt wheels, but won't be able to install them because of the misinformation. setuptools has own requires-python.

So I'm

1. against of raising requires-python
2. pro adding additional vsrsions of Python into CI
3. against dropping old versions of Python from CI

@KOLANICH , agree that it is possible to install on Python 3.6 using pre-built wheels, but that isnt for the average user. I've confirmed this is possible, however I havent tried running the tests on Python 3.6 yet. Can you confirm that the tests all pass on Python 3.6?

Python 3.6 support was dropped in #205 , at least from CI. If we want to keep Python 3.6 support for the 7.x branch, we need to add CI for it, as this is going to be a new major release which means that per semver Python 3.6 needs to be supported until 8.0. Without CI, Python 3.6 support will get broken unintentionally.

ping @pombredanne , you were wanting Python 3.6 support in that PR. If you still want it, I can attempt building some CI for it using pre-built wheels to install it, but it will still be a nightmare to install on Python 3.6 due to https://github.com/pypa/setuptools/blob/main/setup.cfg#L28 being python_requires = >=3.7.

Are there good reasons for keeping Python 3.6 around any longer? It reached end-of-life at the beginning of this year, so I'd vote for dropping it for 0.8.x. As 0.7.x was the first release after a 2 or 3 year hiatus, I understand that dropping it in that series would have been a different story, but I don't think we should keep it around for another release series. Apart from the end-of-life state, not being able to use "new" Python features makes development more cumbersome.

I had a chat with @pombredanne , and @nexB is on Python 3.7+, so no concerns there with dropping Python 3.6 for spdx-tools 7.0.

Great, then let's get going.
I will wait for a few more hours to see if @KOLANICH has further objections, then approve so this can be merged

Can you confirm that the tests all pass on Python 3.6?

They pass except 1 test, test_rdf_parser.py. The order of file_types and files seem to be non-deterministic, sometimes the test passes, sometimes it fails.

To exclude possible non-orderness of dict the following has been done:

__builtins__.dict = OrderedDict

and I got (I added soke dumping and blackened the files)

--- ./result.pon	2022-12-09 00:00:00.000000000 +0300
+++ ./expected.pon	2022-12-09 00:00:00.000000000 +0300
@@ -41,21 +41,21 @@
 		(
 			"files",
 			[
 				OrderedDict(
 					[
 						(
 							"id",
 							"https://spdx.org/spdxdocs/spdx-example-444504E0-4F89-41D3-9A0C-0305E82C3301#SPDXRef-File1",
 						),
 						("fileName", "Jenna-2.6.3/jena-2.6.3-sources.jar"),
-						("fileTypes", ["OTHER", "ARCHIVE"]),
+						("fileTypes", ["ARCHIVE", "OTHER"]),
 						("comment", "This file belongs to Jena"),
 						(
 							"licenseConcluded",
 							OrderedDict(
 								[
 									("type", "Single"),
 									("identifier", "LicenseRef-1"),
 									("name", "LicenseRef-1"),
 								]
 							),
@@ -130,33 +130,33 @@
 							),
 						),
 						("copyrightText", "Copyright 2010, 2011 Source Auditor Inc."),
 						("licenseComment", None),
 						("notice", None),
 						(
 							"checksums",
 							[
 								OrderedDict(
 									[
-										("identifier", "SHA256"),
+										("identifier", "SHA1"),
 										(
 											"value",
-											"2fd4e1c67a2d28fced849ee1bb76e7391b93eb120000000000000000",
+											"2fd4e1c67a2d28fced849ee1bb76e7391b93eb12",
 										),
 									]
 								),
 								OrderedDict(
 									[
-										("identifier", "SHA1"),
+										("identifier", "SHA256"),
 										(
 											"value",
-											"2fd4e1c67a2d28fced849ee1bb76e7391b93eb12",
+											"2fd4e1c67a2d28fced849ee1bb76e7391b93eb120000000000000000",
 										),
 									]
 								),
 							],
 						),
 						(
 							"licenseInfoInFiles",
 							[
 								OrderedDict(
 									[

Without CI, Python 3.6 support will get broken unintentionally.

As you see, it is already.

Are there good reasons for keeping Python 3.6 around any longer?

It is the wrong statement of the question, it encourages dropping support of old versions recklessly. The right one:

Are there any strong reasons for not keeping support of Python 3.6, 3.5, 3.4, 3.3 ...

Someone continues using versions of Python older than 3.6, for example 3.4. Those people cannot upgrade, because there are some people who drop support of versions recklessly. Those people have already dropped Windows XP, and then they have already dropped support of Windows 7.

Dropping 3.6 means 3.7-only features can be brought into the project, that will make backporting the package to 3.4 for those people harder (if anyone needs it, I personally don't use this package on 3.4 machines now, but even one package dropping support of some version creates incentive to other packages to drop it).

reached end-of-life at the beginning of this year

It is just an excuse needed for the ones who think it is nice to have an excuse. If a money-hungry commercial corporation drops support of an old product as just to force people to buy a new product from them, does it mean everyone must drop support of that product? Of course no. It's just the ones who wanna drom use it as an excuse. If there would have been no excuse, they would have dropped it without any excuse anyway.

(Also IMHO it is very strange that SHA1 and SHA256 hashes are almost the same. I guess they are not really computed in this test, but the mere fact of them being the same raises the question)

Are there good reasons for keeping Python 3.6 around any longer?

It is the wrong statement of the question, it encourages dropping support of old versions recklessly. The right one:

Are there any strong reasons for not keeping support of Python 3.6, 3.5, 3.4, 3.3 ...

Someone continues using versions of Python older than 3.6, for example 3.4. Those people cannot upgrade, because there are some people who drop support of versions recklessly. Those people have already dropped Windows XP, and then they have already dropped support of Windows 7.

Dropping 3.6 means 3.7-only features can be brought into the project, that will make backporting the package to 3.4 for those people harder (if anyone needs it, I personally don't use this package on 3.4 machines now, but even one package dropping support of some version creates incentive to other packages to drop it).

And someone might still be on Python 2.x, yet we still dropped it. Maintaining support for an increasing number of old versions steadily increases the maintenance effort, apart from increasing the development effort on account of not being able to use new language features. We don't have infinite resources for maintenance, so we need to make the cut at some point. If someone really critically relies on Python 3.4 support (or any other older version), he/she should speak up and create an issue, so it can at least be discussed.

reached end-of-life at the beginning of this year

It is just an excuse needed for the ones who think it is nice to have an excuse. If a money-hungry commercial corporation drops support of an old product as just to force people to buy a new product from them, does it mean everyone must drop support of that product? Of course no. It's just the ones who wanna drom use it as an excuse. If there would have been no excuse, they would have dropped it without any excuse anyway.

This is getting way too polemic for my taste.

Maintaining support for an increasing number of old versions steadily increases the maintenance effort
We don't have infinite resources

These are the usual excuses. One who wants to do a job, does it, and tolerates the increased effort: doing no job at all requires no effort. One who doesn't do the job, but feels shy to admit it openly, makes excuses. Excuses are not fair. It is far more fair to say "we drop that version because we want to do it and because nothing (like our customers, our boss, our own systems and hardware, etc...) prevents us from doing that", this way explicitly reporting conflict of interests. It is OK to state that you just don't want to do things you are not obliged to do. And it is a strong enough reason (likely, one of the strongest ever possible, you know, users of Python 3.6 are not your employer, so they have no right to require you to do anythkng) not to do anything.

For example none of my packages have supported python 2. In their ReadMe it used to be (untill py2 corpse got decomposed to the point it was officially dropped) written "python 2 is dead, stop raping its corpse". It pretty explicitly tells, that I just don't want to touch the obsolete legacy technology. Not because "maintaince effort", not because "someone has dropped it", but because I just don't want to touch that.

So, please, don't pretend that personal interests of package maintainers and developers to do less work and not to touch legacy are the thing best for the software itself (I know, software is not a really a living thing (but it has some traits of living things!) and doesn't really have "goals" and "interests", but the things best for any software are to increase its value for people, it means being compatible to as much systems and software as possible is always a subgoal of this goal).

+1 to drop support for obsolete versions of Python.