| What 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 there is inevitable firing up of virtualenv, because that's just what you have to do when dealing with messed up dependencies. Next one is new to me. Apparently, one does not just set up git hooks nowadays but use separate tool with declarative config. Because if you ever happen upon something not covered by the Tool, that would mean you are no longer part of the herd. Then we push our stuff straight to pypi, because of course our stuff can't possibly have any dependencies outside of python herd ecosystem. It's not like we knew our dependencies anyway. Then comes the fun part, pulling in tox, because when you have special tool to handle dependencies, what you just need is another tool with different environment and dependency model. Code quality section I will just skip over, seeing what pass for code quality these days makes me too sad.
What follows is setup of several proprietary projects that modern opensource seemingly can't exist without.
What is more interresting is "tyding up" by moving code from git root to subdir. Now, this is of course perfectly sensible thing to, but I wonder why is it called 'src'? Maybe some herd memeber saw compiled language somewhere and picked it up without understanding difference between compiled binary and source code? Now don't take this as if I have problem with the article content in itself. No, as a primer to modern python packaging it's great. It's not authors fault that his work is so comprehensive it lays out bare all the idiosyncrasies, herd mentality, cargocultism and general laziness of python ecosystem these days. Or is it? |
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.