mgorny-nyan (he) :autism:🙀🚂🐧<p>I suppose I could use my experience to give some <a href="https://social.treehouse.systems/tags/PEP517" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>PEP517</span></a> build system recommendations.</p><p>For pure <a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> packages:</p><p>1. <a href="https://social.treehouse.systems/tags/flit_core" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>flit_core</span></a> (<a href="https://pypi.org/project/flit-core/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/flit-core/</span><span class="invisible"></span></a>) — it's lightweight and simple, and has no dependencies (in modern Python versions, for older Pythons it vendors tomli).</p><p>2. <a href="https://social.treehouse.systems/tags/hatchling" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>hatchling</span></a> (<a href="https://pypi.org/project/hatchling/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/hatchling/</span><span class="invisible"></span></a>) — it's popular and quite powerful, but has many vendored dependencies and no stand-alone test suite (which makes it painful to maintain in <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gentoo</span></a>).</p><p>For Python packages with C extensions: <a href="https://social.treehouse.systems/tags/meson" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>meson</span></a>-python (<a href="https://pypi.org/project/meson-python/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/meson-python/</span><span class="invisible"></span></a>) — which combines the power and correctness of meson build system with good very Python integration.</p><p>For Python packages with Rust extensions: <a href="https://social.treehouse.systems/tags/maturin" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>maturin</span></a> (<a href="https://pypi.org/project/maturin/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/maturin/</span><span class="invisible"></span></a>) — which is simply a good builder for precisely that kind of packages.</p><p>Now, I strongly discourage:</p><p>A. <a href="https://social.treehouse.systems/tags/setuptools" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>setuptools</span></a> — lots of vendored NIH dependencies (that can alternatively be unvendored for cyclic deps), lots of deprecations over time (we're still seeing tons of deprecation warnings all over the place), many unsolved bugs (e.g. parallel C extension builds are broken in a few ways), a lot of technical debt, and if all that wasn't enough, it's slow.</p><p>B. <a href="https://social.treehouse.systems/tags/poetry" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>poetry</span></a>-core — a very tricky build system with lots of pitfalls (I've reported a lot of mistakes done when migrating to it).</p><p>C. Practically any other build system — writing new backends is trivial, so everyone and their grandmother must have one. And then, they often carry a lot of NIH dependencies (if you're reinventing a build system, you may reinvent everything else), lack experience and reintroduce the same bugs. And if that wasn't enough, packaging them in distributions is a lot of work for no real benefit to anyone.</p>