[feature] Python3.12 (+Python3.11) support in the testing matrix

[parona-source]

Python3.12 is going to be released in October so getting support for it ready would be an idea. Seeing as the current testing matrix is from 3.7 to 3.10, then at the bare minimum 3.11 could be added and 3.7 could be considered for removal. Python3.7 is EOL, but Debian buster has it and will be EOL'd next year.

I've been using pre release Python3.12 and tests pass fine on dotdrop.

Also moving to PEP517 build system could be an idea, but that's only tangentially related to Python3.12. And while speaking of PEP's PEP668 might cause noise in the issue tracker as it blocks --user installs on the bigger distributions.

[deadc0de6]

Good point. I've added 3.10 and 3.11 and removed 3.6. I'll probably remove 3.7 soon too.

Regarding PEP668, I'm not sure how the different release pipeline will handle it. We'll see in the long run I guess.

For PEP0517, I have to admit I haven't really consider it knowing that the current build system is working pretty well and that dotdrop still support older python versions. I'm also not sure what migrating to it would bring, any insight?

[parona-source]

PEP668 shouldn't affect the releases, it will just cause confusion so users when pip install --user is blocked, and then enable break-my-system-please variable because stackoverflow says to do that :P. This is going to be mostly a documentation problem.

PEP517 is nicety and it should work with older Python releases as it depends on the pip version. In practise moving over might simplify the files in the repo as you have flit, hatch or poetry handling it. And of course building dotdrop changes a bit as python setup.py might not work due setup.py not being there any more. Even so iirc "non pip install" installing gets a deprecation message in setuptools at some point.

[parona-source]

Gave some more though and the biggest thing that PEP668 affects is the submodule way of having dotdrop. PEP668 will block installing the dependencies, so the user would have A) install dependencies on the system package manager B) setup venv for dotdrop dependencies and activate that when running dotdrop.sh C) --break-system-packages.

Plausibly utilisation of a venv could be added to the dotdrop.sh. Biggest downside to that would be that venv is packaged separately on some distributions so that will need to be mentioned.

[parona-source]

If you want read a longer write up on rationale for PEP517 https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html . Removal of non-PEP517 builds shouldn't be an issue now, but setuptools is eye'ing it in the long term.

[deadc0de6]

@parona-source thanks for all your ideas. I have added python 3.11 and opened a dedicated issue to track the migration to PEP517 (#409 ). Regarding PEP668, I added an env variable (DOTDROP_VIRTUALENV that triggers dotdrop.sh to load the env before calling dotdrop). It's not perfect but already allows to transparently use virtualenv with dotdrop. See

• https://dotdrop.readthedocs.io/en/latest/installation/#as-a-submodule-in-a-virtualenv
• https://github.com/deadc0de6/dotdrop/pull/400