Migrate from setup.py + setuptools to pyproject.toml + hatchling

[hugovk]

Fixes #151.

Replaces the deprecated license classifiers with PEP 639 metadata: https://hugovk.dev/blog/2025/improving-licence-metadata/

[hugovk]

TypeError: Field `project.license-files` must be a table

The new metadata isn't supported for 3.6 and 3.7: https://github.com/hugovk/wcwidth/actions/runs/19575036750/job/56057960860

Let's drop them, they've been EOL since 2021-12-23 and 2023-06-27:

https://devguide.python.org/versions/

[GalaxySnail]

By thw way, since setuptools >= 61 supports PEP 621, I think we can use pyproject.toml + setuptools.

[hugovk]

Any particular reason to stick with setuptools instead of something more modern?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (a753ba4) to head (e927f5d).
⚠️ Report is 15 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##            master      #156   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            6         6           
  Lines          100       100           
  Branches        20        20           
=========================================
  Hits           100       100           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[GalaxySnail]

One reason is that we can keep the setup.py in this version, which generates a warning for those who are still calling python setup.py. And since setuptools works well with modern specifications, there's no need to replace it.

[jquast]

I generally support this and have moved to pyproject.toml in other libraries, but the large distribution footprint, including downstream rpm/deb/etc re-packaging, of this library makes me very nervous to make these changes.. see for example #17

So, thank you, I'll consider it for next release, but I'm on the fence. What causes the least amount of "yak shaving" for downstream uses? Currently I'm persuaded to leave it with setup.py for that reason.

[hugovk]

Feel free to close this (and #151) if you like :)

But #17 was reported 10 years ago, which is a long time. pyproject.toml has been around for about that long as well, and I think downstreams have adapted by now.

wcwidth is downloaded some 139,000 times per month.

I checked the top 10 most downloaded projects, which get between 880k and 1.4 billion downloads/month, and they all use pyproject.toml. The number 2 with 1.1 billion, urllib3, uses hatchling as the backend.

No-one should need to invoke setup.py directly any more, even for projects that require a setup.py for C extensions. And especially pure Python projects such as this don't need a setup.py at all.

https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html is the long version, by a maintainer of setuptools.

[jquast]

You’re right that that issue is a long time ago, I will carefully review and merge hope for the best for next release, thanks again for the effort

[jquast]

@hugovk I see you do a lot of these so I want to follow up to tell you that the MANIFEST.in file was not migrated, and this would have distributed an sdist file missing our tests, docs, etc. Luckily I was on the lookout for it because I just happened to have the exact same issue jquast/blessed#341 due to pyproject.toml migration. #178

[hugovk]

Thanks for letting me know, I'll keep an eye out for MANIFEST.in in the future!

Actually, most of the entries aren't needed because by default Hatchling includes everything from source control. Here's a diff of running python -m build --sdist on the repo just before and after #178:

So before did include the tests and docs, and everything that's in the new version.

In fact, it has more stuff, it included the .github CI config, .pylintrc, .python-version-default and .readthedocs.yaml.

It might be worth including those? And it might be easier not having to maintain an include list and just let it include all the source controlled files. Personally I would let it include them, and remove the hardcoded include list, but up to you.

And for some reason, the .gitignore file was excluded afterwards, despite being in the exclude list. I also would just let this file remain, but also up to you. I can find out what we need to make sure to exclude it if you like.

[jquast]

I can only tell you I had different results, I did not use an --sdist argument, maybe something different happened when I use twine somewhere, I really can't say, the folders were missing in the sdist file for me.

[jquast]

I will be investigating re-supporting python 3.6 and 3.7 that were removed by this PR to support improvements to python-prompt-toolkit prompt-toolkit/python-prompt-toolkit#2045 which still uses setup.py and supports 3.6.1 and newer.

[hugovk]

I don't follow, https://github.com/prompt-toolkit/python-prompt-toolkit has pyproject.toml but no setup.py, and supports 3.8+:

https://github.com/prompt-toolkit/python-prompt-toolkit/blob/c7c629c38b22b5f22a0a5e80a1ae7e758ac595bb/pyproject.toml#L23

[hugovk]

Ah, I think your fork is just out of date:

https://github.com/jquast/python-prompt-toolkit/tree/jq/grapheme-clustering-support

They switched setup.py to pyproject.toml in prompt-toolkit/python-prompt-toolkit#1984.

[jquast]

Oh! What a relief, thank you for finding that for me, I'm so bad at the internet sometimes!