Refactoring

[supcik]

I did a refactoring of your program. Here is what I did:

• Migrate font_to_py.py to a Python package (font_to_py).
• Split font_to_py.py into several smaller units.
• Use click for arguments and options processing.
• Add pyproject.toml file to use with poetry.
  • This will check the dependencies.
  • This does simplify the release (poetry build).
  • This provides the font-to-py command.
• Add .pre-commit-config.yaml to apply current Python best practices (Ruff + Black).

Feel free to reject this merge request if you don't like it (I will not be offended ;-)). You can also ask me to make some changes if you want.

[peterhinch]

I'd need convincing to accept this radical change to a mature application. I'm unconvinced of the merits of turning it into a Python package with multiple files. What are the benefits of your changes from the perspective of a user? How would it be installed? Installation of the existing single file is trivial with only one dependency.

I'm happy to run black over the source - I should have done this but it evidently slipped my notice.

[supcik]

Thank you for your feedback. By using Poetry, you will easily be able to publish your software to https://pypi.org/. The name "micropython-font-to-py" is still free, but I warmly recommend you to register your package there as soon as possible (or someone else could do it).

Once that you have an account on pypi, you can upload your software using "poetry publish".

As soon as the code in on pypi, users can install the package using "pipx install micropython-font-to-py". The benefits of "pipx" is that it creates a virtual environment and deal with the PATH. Note that you need poetry (or the old setup.py) to make your script available to pipx.

References :

• https://python-poetry.org/docs/pyproject/#scripts
• https://pypa.github.io/pipx/

P.S. the next step could be to have Github automatically publishing your code to pypi on every new tag... but we can discuss this later ;-)

[peterhinch]

The reason I wrote this as a single file was to make installation trivial. By refactoring it into multiple files it then requires poetry and PyPi, which are indeed great tools for large projects with multiple developers. It seems almost like creating a problem which then requires these tools to solve.

In my opinion this is overkill. Users cope fine with a single file and one dependency.

[supcik]

OK. I understand. I am used to these tools and I prefer modular code, so I will keep my version for me and continue the development in my own repo. Thank you for your feedback.

[peterhinch]

If this were a new project I'd certainly consider designing it in a modular manner. Installation from PyPi is undoubtedly easier, and there are some real improvements like the use of click. However, given the intended audience of firmware developers, installation hasn't been a problem. From my point of view development is essentially complete and I'm unwilling to engage in major changes.

Thanks for pointing out the lack of Pep8 compliance. I will fix this.