Skip to content

Use Hatch for build backend#1644

Merged
facelessuser merged 4 commits into
mainfrom
modernize-metadata
Apr 3, 2022
Merged

Use Hatch for build backend#1644
facelessuser merged 4 commits into
mainfrom
modernize-metadata

Conversation

@facelessuser

Copy link
Copy Markdown
Owner

Supersedes #1640

@gir-bot gir-bot added S: needs-review Needs to be reviewed and/or approved. C: docs Related to documentation. C: emoji Related to the emoji extension. C: infrastructure Related to project infrastructure. labels Mar 24, 2022
Document tests will not work as it requires git history, but docs will
build.
Comment thread pyproject.toml Outdated
Co-authored-by: Ofek Lev <ofekmeister@gmail.com>
@facelessuser

Copy link
Copy Markdown
Owner Author

I was holding out on this as my Python 3.10 would not work with this change. Turned out that the brew install on my mac was just busted in a lot of ways (I hadn't switched over to 3.10 for this and many reasons). So I finally installed the official distribution, and everything worked...go figure.

I may be merging this soon. I realize this is a new build backend, and there are probably not a lot of people using it, so that does give me a little pause, but it does seem to work quite nicely.

I am curious though about what specifically Hatch offers that others don't. I hadn't looked into build-backends until this point, but there are packages like https://github.com/pypa/flit maintained by pypa. What makes Hatch better than others that have a larger community maintaining them?

@ofek

ofek commented Apr 3, 2022

Copy link
Copy Markdown
Contributor

I can briefly tell you why we moved at Datadog!

setuptools

Disadvantages:

  • Support for pyproject.toml-based metadata declaration is experimental atm
  • No support for editable installation standards (PEP 660) so pip install -e ... still requires a setup.py file
  • Based on a deprecated standard library module that it now must vendor
  • Slow to get things merged since the code quality issue is exacerbated by the fact that it is mostly maintained by just one person

Flit

flit-core is the build backend behind Flit.

Disadvantages:

  • No mechanism for extending behavior by design, so we could never do things like versioning with Git tags
  • Very opinionated about project layouts since it targets beginners e.g. only supports implicit namespace packages, must define certain data like __version__ inside the root __init__.py file, etc.

Poetry

poetry-core is the build backend behind Poetry.

Disadvantages:

  • Persistent unwillingness to adopt new standards if they are deemed suboptimal (see comments on PEP 621 and PEP 665)

Hatchling

  • In comparison to setuptools, Hatchling has reproducible builds, supports the modern PEP 660 editable installation standard, has a more intuitive plugin system, and the codebase is an order of magnitude smaller thus making it more auditable and less prone to bugs. For example, the logic to build a wheel resides in this one file.
  • In comparison to flit-core, Hatchling is extensible by design. For example, there is already a plugin for setuptools_scm (which despite the legacy naming is actually now decoupled from setuptools) and a plugin for compiling code with Mypyc.
  • In comparison to poetry-core, Hatchling never strays from community standards and is in fact eager to adopt new ones (it's the only backend that currently supports PEP 639).

@ofek

ofek commented Apr 3, 2022

Copy link
Copy Markdown
Contributor

I don't have a comprehensive list of users yet, but more projects switched recently too like tox

@facelessuser

Copy link
Copy Markdown
Owner Author

Hey thanks for the info. Sounds like hatch is the way to go. Thanks for your help and patience.

@facelessuser

Copy link
Copy Markdown
Owner Author

@gir-bot lgtm

@gir-bot gir-bot added S: approved The pull request is ready to be merged. and removed S: needs-review Needs to be reviewed and/or approved. labels Apr 3, 2022
@facelessuser facelessuser merged commit c5da72a into main Apr 3, 2022
@facelessuser facelessuser deleted the modernize-metadata branch April 3, 2022 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

C: docs Related to documentation. C: emoji Related to the emoji extension. C: infrastructure Related to project infrastructure. S: approved The pull request is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants