setup-dvc
git-hooks.nix
setup-dvc | git-hooks.nix | |
---|---|---|
1 | 6 | |
29 | 449 | |
- | 4.0% | |
3.2 | 9.2 | |
about 1 month ago | 5 days ago | |
JavaScript | Nix | |
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
setup-dvc
-
Pre-commit: framework for managing/maintaining multi-language pre-commit hooks
Here's our setup, which is the result of several iterations and ergonomics refinements. Note: our stack is 90% python, with TS for frontend. Also 95% devs use mac (there's one data scientist on windows, he uses WSL).
We install enough utilities with `brew` to get pyenv working, use that to build all python versions. Then iirc `brew install pipx`, maybe it's `pip3 install --user pipx`. Anyway, that's the only python library binary installed outside a venv.
Pipx installs isort, black, dvc, and pre-commit.
Every repo has a Makefile. This drives all the common operations. Pyproject.toml (/eslint.json?) set the config for isort and black (or eslint). `make format` runs isort and black on python, eslint on js. `make lint` just verifies.
Pre-commit only runs the lint, it doesn't format. It also runs some scripts to ensure you aren't accidentally committing large files. Pre-commit also runs several DVC actions (the default dvc hooks) on commit, push, and checkout. These run in a venv managed by pre-commit. We just pin the version.
Github actions has a dedicated lint.yaml which runs a python linter action. We use the black version here to define which black pipx installs. We use `act` if we wanna see how an action runs without sending a commit just to trigger jobs.
As an aside, I'm still fiddling with the dvc `pre-commit` post-checkout hooks. They don't always pull the files when they ought to.
Most of the actual unit/integration tests run in containers, but they can run in a venv with the same logic, thanks to makefile. We use a dvc action to sync files in CI.
So yeah there's technically 2 copies of black and dvc, but we just use pinning. In practice, we've only had one issue with discrepancies in behavior locally vs CI, which was local black not catching a rule to avoid ''' for docstrings; using """ fixed it. On the whole, pre-commit saves against a lot of annoying goofs, but CI system is law, so we largely harmonize against that.
IMHO, this is the least egregious "double accounting" we have in local vs staging ci vs production ci (I lost that battle, manager would rather keep staing.yaml and production.yaml, rather than parameterize. Shrug.gif).
Technologies referenced:
https://dvc.org/
https://github.com/iterative/setup-dvc
https://github.com/marketplace/actions/python-linter
https://github.com/nektos/act
git-hooks.nix
-
Fast, Declarative, Reproduble and Composable Developer Environments Using Nix
> Good luck getting answers on those questions other than "read the source code" and then followed by "no, not that source code, this branch here".
I experienced a similar situation last week with git-hooks.nix[1], a pre-commit integration for Nix.
I wanted to run biome[2] checks on my repository during pre-push so I wrote a custom hook because git-hooks.nix has pre-defined integrations with prettier and rome, but not biome.
Or that's what I thought. I eventually found out that the rome hook is actually referred as "rome" everywhere but calls biome instead[3]. This wasn't documented anywhere, so I opened an issue[4] suggesting to rename the hook to "biome" and keep the former for backwards compatibility reasons.
As of today, this has been acknowledged by one of the maintainers, whose sole feedback has been to "thumb down" the issue.
TL;DR: It's not just the documentation, but also the code not doing what you would expect. It also seems there's no means to improve the situation other than just forking the project since there's also clearly some kind of communication problem.
[1] https://github.com/cachix/git-hooks.nix
-
Any good alternative to husky in rust to enforce and write conventional commits and for pre-commit source code linting??
Anyone who already uses Nix and Flakes can use this integration. Anyone who doesn't use Nix can just ignore me, because I'm not here to try converting unconvinced folks.
-
Plugin devs: type check your lua plugins with lua-language-server and EmmyLua (GitHub action)
I don't think it does. I might look into implementimg it though, because I use pre-commit-hooks.nix in my own projects' CI.
-
Pre-commit: framework for managing/maintaining multi-language pre-commit hooks
> My least favourite bug is that it doesn't always play nicely with NixOS [1], and the maintainer locked me out of the issue for pointing it out.
Oof. Does this solve the problem https://github.com/cachix/pre-commit-hooks.nix (using Nix to manage dependencies)?
I was looking at pre-commit the other day, and wanted to incorporate it into the Nix setup of my projects.
-
y|sndr - Hooking up with Git - A nix managed solution to git hook management
Was it not possible to use something like this? https://github.com/cachix/pre-commit-hooks.nix
-
Statix — Lints and Suggestions for the Nix programming language
Maybe consider adding this to https://github.com/cachix/pre-commit-hooks.nix once you feel it's mature enough.
What are some alternatives?
pip-audit - Audits Python environments, requirements files and dependency trees for known security vulnerabilities, and can automatically fix them