The latest articles on DEV Community by Robert Roskam (@raiderrobert). https://dev.to/raiderrobert https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F229995%2F44c5cc0d-b3ad-48ce-934b-1f49f4d045c9.jpg https://dev.to/raiderrobert en Robert Roskam Wed, 16 Oct 2019 19:44:52 +0000 https://dev.to/raiderrobert/python-tooling-review-pyproject-toml-and-flake8-45bb https://dev.to/raiderrobert/python-tooling-review-pyproject-toml-and-flake8-45bb <p>I recently had an opportunity to review some tooling for Python, and I thought I'd share some of my learnings.</p> <h1> pyproject.toml </h1> <p>This fancy new file is the replacement for <code>setup.py</code> and <code>setup.cfg</code> originally specified in PEP 518 (<a href="https://www.python.org/dev/peps/pep-0518/">https://www.python.org/dev/peps/pep-0518/</a>).</p> <p>Simple and clean explanation, right? Well, no, not really.</p> <p>Since its release, it's now the exclusive way to configure <code>black</code> for a project. Additional tools like <code>poetry</code> (somewhat of a <code>pipenv</code> competitor) and <code>flit</code> (a tool to make packaging and publishing to PyPI easier) have come out to also exclusively use <code>pyproject.toml</code> as their configuration file.</p> <p>It's clear from the PEP that this was the intended consequence for other tools to use <code>pyproject.toml</code>. However, it seems to only have really touched brand new projects. Older, mature packages seem to still primarily be using <code>setup.cfg</code> for their tooling configs in their CI process.</p> <p>I generally tend to adopt new trends like these in my <em>projects</em>, but in my existing <em>packages</em> I admit not seeing a whole lot of value presently in ripping out my <code>setup.py</code> and <code>setup.cfg</code> just for fun.</p> <h1> flake8 </h1> <p>I used pylint for a very long time while at Worthwhile and began using flake8 at Peerfit. I really had no opinion of one over the other.</p> <p>However, I can say now that holy crap does flake8 have so much stuff.<br> It wraps pyflakes, pycodestyle, and mccabe. Additionally, it's just got so many plugins: flake8-bugbear, flake8-import-order, flake8-print, etc (<a href="https://github.com/DmytroLitvinov/awesome-flake8-extensions).This">https://github.com/DmytroLitvinov/awesome-flake8-extensions).This</a> rich ecosystem simply doesn't seem to exist for pylint.</p> <p>Finally, a lot of major projects seems to use flake8, so the user base is consistent and mature:</p> <ul> <li>Django (<a href="https://github.com/django/django/blob/master/setup.cfg#L5">https://github.com/django/django/blob/master/setup.cfg#L5</a>)</li> <li>flask (<a href="https://github.com/pallets/flask/blob/master/setup.cfg#L22">https://github.com/pallets/flask/blob/master/setup.cfg#L22</a>)</li> <li>even freaking youtube-dl (<a href="https://github.com/ytdl-org/youtube-dl/blob/master/setup.cfg">https://github.com/ytdl-org/youtube-dl/blob/master/setup.cfg</a>)</li> </ul> <p>So this has sold me on using flake8 for the foreseeable future.</p> python tooling packaging