Drop3.6 & move all configuration into pyproject.toml #49
Conversation
Teque5
changed the title
|
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 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. |
|
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. |
|
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? |
|
Probably 1.2.0 |
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 |
|
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. |
* tox configuration simplified and consolidated to pyproject.toml * default configuration for common tools (black, pytype, coverage) * add entry point for sigmf_convert_wav * slightly improve sigmf_convert_wav * increment to v1.2.0 * move tools/ to apps/ * move gui.py to apps/ * drop support for python 3.6 * add support for python 3.12 * distribution previously made with setup.py can be created w/python3 -m build * upgrade logo to SVG version
|
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
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 Considering the above it seems to me freeing our version from the spec would make sense. |
|
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 |
Generally folks have been moving away from the setuptools based installer and preferring a
tomlconfiguration since it allows all configuration to be in a single location.toxconfiguration simplified and consolidated topyproject.tomlblack,pytype,coverage)sigmf_convert_wavsigmf_convert_wavv1.2.0tools/toapps/gui.pytoapps/setup.pycan be created w/python3 -m buildOne 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>65so 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.