pytesseract icon indicating copy to clipboard operation
pytesseract copied to clipboard

Migrate to pyproject.toml

Open egeakman opened this issue 2 years ago • 6 comments

Updates:

  • Fully migrated to pyproject.toml
  • Added formatter and validator for pyproject.toml to pre-commit config

Ideas:

  • We could use hatchling as the build backend

Here is an example project using hatchling and pyproject.toml.

To build:

python -m pip install build
python -m build

This builds a wheel and a tar under dist/, ready to ship.

egeakman avatar Dec 29 '23 17:12 egeakman

Ping @bozhodimitrov

egeakman avatar Jan 05 '24 15:01 egeakman

Which advantages/disadvantages can be expected with this approach?

stefan6419846 avatar Jan 05 '24 15:01 stefan6419846

Basically, pyproject.toml is the modern and standardized way for most Python packages.

Here are some more specific advantages and disadvantages of pyproject.toml:

Advantages:

  • All metadata and tool configuration in one place: less files (3 -> 1) to worry about.
  • Tool-agnostic: supports multiple build-backends like hatchling (unlike setup.py which only supports setuptools).
  • Tool integration: popular tools like black, isort, ruff, ... can be directly integrated.

Disadvantages:

  • Might not be the best option if dynamic or system-specific build logic is required (which is not for this project).
  • Requires an extra package to be installed: build, but it is already the recommended tool (by PyPA) for creating source distributions and wheels.

See also: Simon Willison's blog post, PEP 517, PEP 518

egeakman avatar Jan 05 '24 21:01 egeakman

I'm more drawn to using hatchling these days. Here is an exhaustive answer to "Why Hatch?".

I can edit the PR to use hatchling instead of setuptools, just let me know.

egeakman avatar Jan 05 '24 22:01 egeakman

Kindly pinging again @stefan6419846. If this project needs more love, I'd be more than happy to help with basic maintenance/triage.

egeakman avatar Jan 08 '24 07:01 egeakman

I have no strong opinion on the build tools itself - if you have a look at my own repositories, you will see that I still mostly use the traditional setuptools approach with setup.py, although with the latest commands. For this reason, I personally do not see the direct need to migrate anything here unless there are actual maintenance benefits.

Leaving this aside: I am just a contributor here, no maintainer/collaborator, thus I am not able to decide this anyway ;) I am sure that the maintainers come back to you once they find appropriate time.

stefan6419846 avatar Jan 08 '24 07:01 stefan6419846