Introduce poetry and tox in parallell with original setup

[oysteoh]

Deleted my previous PR and creating a new one where i introduce poetry and tox in parallell with what is already present. This allow for usage of both, and over time hopefully get rid of Makefile, requirements.txt, setup.py and setup.cfg. In addition i added a new GA file utilizing poetry and added matrix build verifying all python versions from 3.10-> 3.13. Moved pyeasee underneath a new src folder as of best-practice.

I think this PR ( with improvements if needed ) if aligned with what you think should be done with the project is a better place to start than my previous at it allows for you to continue as you have done, but with the possibility of using poetry to i.e. handle dependencies and updating those as we go.

Feel free to provide any feedback 👍

[Hellowlol]

Where can i read the best practice for using src?

[oysteoh]

Many places, amongst many i guess this is one of the more official explanations https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/

[astrandb]

Thank you @oysteoh for your work on this PR. We (@olalid and myself) have discussed the way forward with your suggestions and our thoughts can be summarized as follows:

• This library is a small project with few contributors, few dependencies and few use cases - in is mainly aimed at interfacing our integration easee_hass for Home Assistant even if we know that there are a handful of other independent uses.
• We don't foresee a need for frequent updates and releases of the library. Say a couple of releases per year, mainly to keep up with changes in the Easee public API and the Home Assistant ecosystem including supported Python versions
• We want to keep the environment for development simple to use and simple to maintain.
• There has not been any major issues with code quality so far.
• None of us maintainers are prepared to invest significant amount of time and effort in developing comprehensive automated testing.
• We have no real experience with poetry and tox.

That said, we are happy to move forward with modernizing the development environment. A few bullet points to consider:

• Keep the PR:s small to simplify review.
• Make each PR mergeable by itself - if possible.
• Create separate PRs for resulting reformatted code and other linter changes - to simplify review and to avoid regressions.
• Think about the development flow and release process. Home Assistant and our dev container for the integration use pre-commit to detect and fix most formatting and quality checks before committing the changes.
• Move from isort/flake8 to ruff as primary linting tool to align with HA coding practice.

Looking forward to your comments.

[oysteoh]

I would say your comments is perfectly aligned with my expectations. I understand this project is small and not very complex - but i noticed it while looking for easee-integration towards my HA - and i want to contribute if it is needed and wanted. As a software developer i noticed right away some small things i could improve. I have some hopes of adding testing and improve the test coverage making it easier to refactor and make changes when needed, but probably not suggest to many things. I am perfectly aligned with your wish on commits which could be merged ( they should make all tests pass ). I'm not sure if you want just one commit pr PR? ( it is easy to select each commit in my PR to see the changes as they are made ).