Support pyproject.toml

[loeschzwerg]

This is more of a suggestion/scaffolding, than a pre-cooked pull request.
I just found this repository and thought "Cool, I think I might use that for other projects".
The repository did not work out of the box, and there is not really much of a development quickstart.
So I went ahead and kickstarted my development environment.

This is where this PR comes in.
It doesn't deliver the pyproject.toml, but an evaluation environment for the maintainers.
Many build-tools migrate to pyproject.toml, as it finally solves this hassle with packaging nightmare.
https://packaging.python.org/en/latest/guides/writing-pyproject-toml/

If you would like to try a build-tool that gained significant attention in the last time, I recommend uv: https://astral.sh/uv (pip install uv)
It allows automatic venv-management and build tool execution.

Obviously the pyproject.toml is far from merge (e.g. authors...)

But because the project was actually running smoothly with just basic configuration, I felt the maintainers appreciate such ease of use.

What I did to get to this point was rather simple:

# get up and running
uv init --build-backend=setuptools
uv add requests

# to list all available run endpoints
uv run

# and then try the cli
uv run fritzconnection

# and I even tried some build tooling
uv add --dev nox
uv run nox

[kbr]

Thanks for your ideas. Replacing the old fashioned setup.py by pyproject.toml is indeed on the bucket list for the future. Regarding uv: as astral has been aquired by OpenAI the future of uv may be bright or not. We will see. Beside this I'm more team pixi. In case you want to have a closer look: https://pixi.prefix.dev/

[loeschzwerg]

Thank you for the suggestion. I did not know about pixi. I did not notice the acquisition. But I have to say for the time being I am happy with uv. I estimate that this acquisition will make uv the standard package manager for python in the long run. I also see that pixie is using uv under the hood already. I will definitely add pixie to my repertoire.

If you like, I can work towards a pyproject.toml using setuptools as a starting point. Obviously I have to find the time...

I think the CLI can also be improved a bit, so I would use this PR as a starting point to get to know the package better, before diving into the CLI or even a TUI (as if that does not require time...)

[kbr]

Thanks for your contributions. Regarding uv, the difference on pixi is conda-forge first and that pixi can resolve packages installed via conda and pypi. Not a trivial task. uv works as a replacement for a pip/nox combination. As a lot of Python infrastructure tools are rewritten in rust, uv is fast (may be also something has changed on the resolve algorithm). This is convenient and often a reason for hype and traktion. We will see. pixi adds conda-forge-first on top. That is a real advantage, even if not needed by a broad audience.

Regarding the pull-request: the road map is to roll out version 2 first (which has a lot of internal refactoring) before adding even more changes. There still are some fixes needed, test adaptions waiting and also a rewrite of the cli to provide some basic commands by a single tool.

From that on more changes/features can be added. Your idea about a TUI may be something to consider.