cool - there's a lot of overlap with the "Hypermodern Python"[1] so if anyone enjoyed this and wants to read more, they might also enjoy that.
[1]: https://cjolowicz.github.io/posts/hypermodern-python-01-setu...
How to create a Python package in 2022
91–100 of 153 posts
Re: How to create a Python package in 2022
#92Earlier quoted context omitted.
Your nitpick is forgiven! Thanks a lot for this information, I was not aware of this... However, I took a look at PEP 518 and failed to understand what was wrong with Poetry's default configuration. Can you help me out?
It's actually PEP 621 ( https://peps.python.org/pep-0621/ ) that the OP meant to refer to. IIRC, there's work ongoing in Poetry to allow it to support PEP 621.
Yes, I meant PEP 621. Thanks for the correction!
Re: How to create a Python package in 2022
#93Fantastic article. A clickable TOC at the top would be a great addition.
Re: How to create a Python package in 2022
#94I wish people would just forget about pre-commit, this thing is especially useless in a setting where a CI/CD pipeline exists. It's not that hard to write a simple Makefile or shellscript to run linters on push. Pre-commit is one of the most annoying tools that have come into existence in recent years that everyone seems to be cargo-culting. It doesn't play well with editors since in order to find the actual binary p…
Pre-commit running tools in it's own virtual environment is a feature, not a bug, in my book -- it means that the dependencies for my linter tools aren't mixed in with the dependencies for the code I'm writing.
And, keeping things separate from setup.cfg or pyproject.toml is optional: The tools still look for configuration in their usual places, so it's still possible have your black options in pyproject.toml and just a bare-bones entry to call black in your .pre-commit file if you prefer.
Re: How to create a Python package in 2022
#95What a great article. We start with learning that we absolutely need this Poetry thing because… it's what everyone else uses. It's refreshing to see author who can skip usual badly argued justifications and just plain admin that he does not know shit and is just following rest of the herd. Then we continue by "solving" depependencies by usual way of ignoring them and just freezing whatever happens to be present. Then…
the irony here is python packaging has sucked forever, and this is just another example of it. "Do more with less" has never entered the average python developers mind. you'd think herd mentality might help it but it only creates more packaging solutions. Now days, I've stopped using python outside of tiny scripts and I will never touch it for a large project.
The problem with Python is it's too successful. It has too many useful libraries. I don't really like it very much but it's really hard to ignore it.
There is exactly one thing I miss from Python packaging tools: developer mode. I can factor out parts of an application into a library and develop both at the same time by installing the library in editable mode and pointing to the library's local directory. This is something I've always wanted but never had in every other language I know. Only god knows how much time I spent trying to do exactly this with git submodules.
Re: How to create a Python package in 2022
#96Earlier quoted context omitted.
> The CI/CD pipeline is there to give the team the confidence to merge your stuff. That's why linting is a part of every CI stage. Linters check your code for bugs. > Have your team installed hooks that take a long time to run? Yes, they are called tests.
Wait, you're not supposed to run tests with pre-commit. I can see why that would be frustrating. If that's the case, your team is doing it wrong.
Perhaps, but it's not just one team, and if you are doing code quality checks on CI anyway, I don't see the point of pre-commit (for most people).
Re: How to create a Python package in 2022
#97What a great article. We start with learning that we absolutely need this Poetry thing because… it's what everyone else uses. It's refreshing to see author who can skip usual badly argued justifications and just plain admin that he does not know shit and is just following rest of the herd. Then we continue by "solving" depependencies by usual way of ignoring them and just freezing whatever happens to be present. Then…
> Poetry thing because…
pip freeze doesn't pin transitive dependencies and so you have to pick something and Poetry is fine and actively developed.
> virtualenv, because that's just what you have to do when dealing with messed up dependencies
No that's what you do when you have multiple dependency trees for different projects on your system. Somehow people got the message that global variables were bad but still think that "random bullshit strewn on my specific system" is a great way to make software that works on other people's machines.
> Because if you ever happen upon something not covered by the Tool
You write your own hook because it's entirely plugin based.
> tox, because when you have special tool to handle dependencies, what you just need
A tool that doesn't pollute your development environment with testing packages and doesn't run your tests in your development environment, hygiene that before this tool basically nobody bothered to do because it was tedious.
Re: How to create a Python package in 2022
#98I wish people would just forget about pre-commit, this thing is especially useless in a setting where a CI/CD pipeline exists. It's not that hard to write a simple Makefile or shellscript to run linters on push. Pre-commit is one of the most annoying tools that have come into existence in recent years that everyone seems to be cargo-culting. It doesn't play well with editors since in order to find the actual binary p…
Pre-commit running tools in it's own virtual environment is a feature, not a bug, in my book -- it means that the dependencies for my linter tools aren't mixed in with the dependencies for the code I'm writing. And, keeping things separate from setup.cfg or pyproject.toml is optional: The tools still look for configuration in their usual places, so it's still possible have your black options in pyproject.toml and jus…
Except your usual configuration don't necessarily work for your pre-commit hooks. A prime example is mypy.
Re: How to create a Python package in 2022
#99Lot of good info and saved away! However, it drinks the code coverage cool-aid that started like 30 years ago when code coverage tools emerged. Management types said "high test code coverage == high quality"; lets bean count that!! A great way to achieve high code coverage is to have less than robust code that does not check for crazy error cases that are really hard to reproduce in test cases. Code coverage is a too…
Python is the language with one of the highest 100%-coverage-to-effort ratios. The included unittest.mock framework is making it quite easy to trigger obscure errors and ensure they are handled properly. Combined with thoughtful use of `# pragma: no cover` a 98% code coverage nowadays is an immediate warning that something was rushed. With this and type checking I feel RuntimeErrors much easier to avoid these days. A…
From the point of view of a programmer setting up a new project, type checking tools are yet another optional linting operation that can be integrated in pre-commit hooks or other automation.
Re: How to create a Python package in 2022
#100Earlier quoted context omitted.
Pre-commit is optional, you can just not install them into .git/ ... Although I'd indeed prefer just before push, or just make display warnings One thing that's really annoying these days are CI/CD that can't be replicated locally, generating quite annoying delays in the development. Jenkins seems particularly problematic in this regard: the steps get encoded in some cryptic pet Jenkins server, and then you have to w…
> One thing that's really annoying these days are CI/CD that can't be replicated locally pre-commit just runs your linter, formatter and tests. Surely you can fully replicate this step locally. Just run make lint both locally and on CI. Anything else that's hard to replicate has to do with the distributed systems that you are probably working on because these systems are all probably proprietary stuff that live on th…
My point is that using these tools at least makes people put these scripts within the repo instead of just in the CI server.