Penultimate Guide to Python Packaging If you came here hoping to finally find the answer about how to correctly create python packages you will have a big dissapointment. I will be very happy to replace this article with one that gives a decent recipe any packager can follow for producing sdists and wheels. pyproject.toml hidden gems If you dare to create a pyproject.toml file for your project you will use the ability to make editable installs with pip.
Places where we may want to expose the release notes: PyPI project description page, but most projects do not list changelogs there unless they happen to keep them in their main README. GitHub Releases page, a very good place to see what is new, also allowing you to watch new releases on that project. Published documentation Git changelog does not replace release notes Looking at git changelog is not the most fulfilling experience as it can contain too much noise, like multiple attempts to reconfigure CI, lots of gradual changes that do not worth mentioning like fixing linting rules.
This article assumes you are already familiar with flake8. Probably you faced at least one of the challenges below related to: adoption requires a lot of code reformatting some rules contradict each other, like W503/W504 different rules on different projects newer versions requiring rework … why I am wasting my time with linting Years ago, OpenStack team release a package named hacking which aimed to address some of the problems listed above.
Writing easy to maintain Ansible roles and playbooks is more of secret art that will take years to master. Product documentation is useful but is far from complete and lacks lots of hints.
List the tests pytest --collect-only Run only specific tests If you want to run only tests that have ‘foo’ in their name or path, it is as easy as: pytest -k foo Limit which tests run by using markers Test markers are like ansible tags. Some labels can be assigned to tasks and you can decide which one you want to run or skip. They can be hardcoded in test definition or added dynamically.
Using when conditions in Ansible for adding support for multiple platforms and their versions does not scale well. As soon you need to support more than two versions it will hit you hard and make your code hard to maintain. The trick is to load tailored presets for each platform and version when your role starts and use these values of these variables when performing tasks. Most of the time this saves you from adding conditions to tasks.
What it does? GRI lists reviews in a compressed format which also allows you to click either review number of topic to open them in your browser, if your terminal supports hyperlink extension. Since I created that tool the number of open reviews I had went down considerably and I suspect that its ability to focus on reviews that are likely to merge or to be abandoned helps cleaning up the queus.