[no squashing please] Introduce simple pyproject.toml packaging

[hartwork]

In reaction to k4rtik/pydf-pypi#9 (comment)

For a future v16 release, the local release process would be something like this:

rm -Rf pydf.egg-info/ && python3 -m build
twine upload dist/*16*

PS: The current pydf license seems to be somewhere on the spectrum between "some version of public domain" and WTFPL. I have applied CC-PDDC here (because SPDX does not know "public domain") but please check the list of options at https://spdx.org/licenses/ for a better matches, happy to adjust. I should note that because "public domain" and CC0 (or CC-0) were a legal problem to Fedora, some projects started using e.g. 0bsd instead.

CC @garabik @k4rtik

[k4rtik]

Suggested change

	requires-python = ">=3.10"
	requires-python = ">=3.4"

According to vermin, 3.4 is the min version supported:

❯ uvx vermin --no-parse-comments -v .
Detecting python files..
Analyzing 2 files using 12 processes..
2.6, 3.0     /Users/kartik/GH/pydf/attic/gs.py
!2, 3.4      /Users/kartik/GH/pydf/pydf
Minimum required versions: 3.4
Incompatible versions:     2.x

where

❯ uvx vermin --no-parse-comments -vv .
[...]
!2, 3.4      /Users/kartik/GH/pydf/pydf
[...]
  'os.path.ismount' member requires !2, 3.4
[...]

[hartwork]

@k4rtik interesting command! I would like to stick to >=3.10 because <=3.9 is very dead: https://endoflife.date/python

[k4rtik]

Yes, I am aware of that. The INSTALL file currently says this project needs at least 3.1, so I thought there might be an interest in supporting older versions for a system utility like pydf.

[hartwork]

My personal vote for killing all remains of <3.10 with fire. I see your point about things being in sync. The PR here is in sync with CI is currently doing. @garabik are you on board with me dropping official remains of <3.10 support (a) in here or (b) in a follow-up PR?

[garabik]

I very much agree with @k4rtik there is an interest in supporting older python versions (I am myself in such a position, I have accounts on some servers that Are Not To Be Touched with upgrades). Having said that, I agree with dropping <3.10 support officially, esp. for pypi, as long as we do not introduce syntax errors into the tool itself needlessly...

[k4rtik]

This is good, I highly recommend updating the README as well, see https://packaging.python.org/en/latest/guides/making-a-pypi-friendly-readme/

[k4rtik]

Suggested change

	"Programming Language :: Python :: 3.10",
	"Programming Language :: Python :: 3.11",
	"Programming Language :: Python :: 3.12",
	"Programming Language :: Python :: 3.13",
	"Programming Language :: Python :: 3.14",

I'd avoid these for maintainability.

[hartwork]

@k4rtik adding support for 3.15 and dropping support for 3.10 needs touching some files in any case and this is a place where I would know to check and the fix being trivial: I'm touching these in a number of projects and that part has never been a personal pain point for me. I'm good with keeping or dropping them here, with a preference to keep. @garabik how do you feel about these?

[hartwork]

This is good, I highly recommend updating the README as well, see https://packaging.python.org/en/latest/guides/making-a-pypi-friendly-readme/

@k4rtik interesting pointer! I can provide a follow-up pull request, the readme was a topic in a call with @garabik at some pont briefly, but I think #10 was not yet merged and I wanted to avoid conflicts. Good point 👍