Live data from Hacker News

How to create a Python package in 2022

mathspp.com

151–153 of 153 posts

Re: How to create a Python package in 2022

#151
post #110
post #57

I 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 can also be configured to use the project's dependencies, which is what I do with my repos when there is overlap. You don't have to use its built-in integrations. Indeed, I find its integrations most useful for tools that aren't specific to my project: things like the white-space checks, yaml checks, etc. You can also set things up the other way around, having the CI/CD system install and and run pre-commi…

As another dev with decades of experience, I've got to ask, why would you "validate" every commit in a PR lol. The reason every CI pipeline is setup to only validate the tip is because your combined outgoing changes that is about to be merged is all that matters. Nobody cares if you have an experimental branch full of commits failing lint and tests as long as the PR doesn't.

However, in my experience, I've seen plenty of pipelines setup to run lint on every push on a PR branch, which is effectively only checking outgoing changes before merge, it's just in this case it's merging to your feature branch. My point still stands - as long as linting is done on CI, and you've set up your editor to lint as you edit, you don't need pre-commit.

I'm not entirely sure what point you are trying to make. It sounds like all you've done is moved all of the tools you'd call anyway from a Makefile to a YAML file.

Re: How to create a Python package in 2022

#152

Earlier quoted context omitted.

Well I have different experiences where no one would ever go back to living without pre-commit, black, autoflake, etc. It moves the fixes to before they get to CI. There's literally no downside. Maybe you have experience with some weird tool? Or running black and autoflake messed around with emacs and it needs to reload all the buffers?

I initially had some problems, then I've written an emacs package[1] to fix all of them. And it's due to the course of writing this package made me realize just how bad pre-commit is from its UX, design to its entire premise. [1]: https://github.com/wyuenho/emacs-python-exec-find

Ok then I think the issue is not so much pre-commit but that python tooling in general should not be written in python. It's a minority opinion but the fact that there is a tooling python and an application python can mess with things as you're experiencing.

Re: How to create a Python package in 2022

#153

Earlier quoted context omitted.

Tell me you use Emacs without telling me you use Emacs.

Not sure why, though? I've used emacs for 15 years and pre-commit for probably 5 years at this point.

Are you using git inside Emacs or from the command line? It seems GP is doing everything in Emacs and application python resolution is tripping up with tooling python.

If you have it all sorted out from Emacs maybe check the repo they posted which tries to do all this.

Post reply on HN