Drop3.6 & move all configuration into pyproject.toml

[Teque5]

Generally folks have been moving away from the setuptools based installer and preferring a toml configuration since it allows all configuration to be in a single location.

• tox configuration simplified and consolidated to pyproject.toml
• configuration for common tools (black, pytype, coverage)
• add entry point for sigmf_convert_wav
• add argparse for sigmf_convert_wav
• increment to v1.2.0
• rename tools/ to apps/
• move gui.py to apps/
• official support for python 3.12
• distribution previously made with setup.py can be created w/python3 -m build
• upgrade logo to SVG version
• drop python3.6 support (incompatible setuptools dependency)

One merged I'll tag and create a release.

Drop 3.6 support?

I see now that the automated build is failing with python3.6. I require setuptools>65 so that the toml will dynamically get the version from the module. The minimum version for that version of setuptools is python3.7.

I added another commit that solves this issue.

[gmabey]

So, it looks like the on-life-support timespan for RHEL/Rocky 8 is mid 2029: https://access.redhat.com/support/policy/updates/errata#RHEL8_and_9_Life_Cycle That makes me think that we'll be persuaded to drop Python 3.6 before RHEL is actually EOL.

The question then is, how much support should be offered to those users (if any).

For my purposes, I suspect that continuing to use sigmf-python 1.1.5 might be fine (even if 1.1.6 doesn't).

If it isn't perhaps a new branch could be created, and users could submit (if they are really motivated) patches to sustain a 1.1.5.x series. That would be preferable to seeing folks fork the project, IMHO.

Another option would be to graduate to 1.2.0 with this change.

[Teque5]

Ubuntu 18.04 is EOL in April and uses 3.6, but the next ver of Ubuntu is using 3.8 as system default.

Worth noting that according to the python foundation 3.6 has been EOL since the end of 2021.

[777arc]

Oh actually I just noticed there's still a "3.6+" in the README

[Teque5]

Oh actually I just noticed there's still a "3.6+" in the README

I'll fix this. Do you think we should go to 1.2.0 or just increment to 1.1.6?

[777arc]

Probably 1.2.0

[gmabey]

I'll fix this. Do you think we should go to 1.2.0 or just increment to 1.1.6?

One reason to vote for 1.1.6 is (not sure if this is valid) to try to have the major and minor numbers match those of the SigMF spec release ...

[Teque5]

I'll fix this. Do you think we should go to 1.2.0 or just increment to 1.1.6?

One reason to vote for 1.1.6 is (not sure if this is valid) to try to have the major and minor numbers match those of the SigMF spec release ...

I hadn't thought of this. Usually I think about versioning as major.minor.patch and I thought we had decoupled from the SigMF spec version. Tracking the spec is an interesting idea but it would be out-of-the-ordinary.

[gmabey]

I agree that given the scope of the changes, something other than patch-level increment seems appropriate. The idea is to try to avoid a separate table/reference that indicates which version of the spec that a particular version of sigma-python supports.

[Teque5]

Okay well it's all ready to merge but I don't know if we are decided on the versioning. The versioning for the SigMF spec needs to be sorted out as I mentioned here but currently is using it's own major.minor.patch scheme.

The idea is to try to avoid a separate table/reference that indicates which version of the spec that a particular version of sigma-python supports.

In prior discussions on this topic we considered having 1 or more schema in this repo for each version of SigMF, however recently there was an effort to add the schema to the spec repo. It would be reasonable to have this module always track the most recent version of the spec, but if we were to support prior specifications a simple option would be to have the spec as a git submodule, or a table as you were deign to suggest.

Considering the above it seems to me freeing our version from the spec would make sense.

[777arc]

I don't like the idea of trying to keep the python module version and SigMF spec version matching, they will each be bumped for their own reasons. We are moving towards having the specs ultimately live within a json schema file in the other repo, so it would be good for this repo to no longer have a separate version of that file, since we are going to be refining the other one quite a bit. I don't have any strong opinions as far as whether to git submodule or to be able to pull in multiple (older) versions of the specs schema. That being said we do want to make sure the json schema is always available at a specific URL, eg https://github.com/sigmf/raw/somethingsomething