Consider moving linting to pre-commits

[ocefpaf]

Pre-commits are fast, run separate from the GitHub Actions CIs, and allow for quick "lint fixes" directly the the PR.

[ChrisBarker-NOAA]

Yes, this makes sense -- as long as we're saying the lint needs to pass, putting it in a pre-commit makes more sense.

I don't know how to set that up -- but if you can do it, that would be great.

[ChrisBarker-NOAA]

Thinking more -- does that mean folks couldn't commit (push) if the lint failed?

I'm not sure I want to be that pedantic.

Can we allow not-perfect code to get pushed to branches, and only require the lint to pass in order to to merge to main?

[ocefpaf]

Thinking more -- does that mean folks couldn't commit (push) if the lint failed?

No, they can set it up locally if they want that.

Can we allow not-perfect code to get pushed to branches, and only require the lint to pass in order to to merge to main?

It will fail the pre-commit-ci, that is exactly the current behavior. The differences are that we can fix most of it with a bot command, no need to bother the user, and it will separate GitHub Actions CIs from the linting CI.

[ChrisBarker-NOAA]

Is this it?

https://pre-commit.ci/

Sounds good -- if you want to set it up, then go for it.

[ocefpaf]

@MathewBiddle or @mwengren, I made the request for pre-commit-ci here. You should get it in your GH notification. Can you enable it for us?

[mwengren]

Approved. We're still enabling repo-by-repo, so this one is now added.

[ocefpaf]

Approved. We're still enabling repo-by-repo, so this one is now added.

It is better to do it repo-by-repo. Otherwise repos that don't require it will always show a pre-commit-ci failure due to lack of config file.

[ChrisBarker-NOAA]

It looks like maybe you can do, well, anything n a pre-commit.

In which case, I'd like to run a little script that builds a conda_requirements_all.txt file.

Why?

Because conda doesn't have a way to combine different requirements files (or environment files) -- which is a pain -- I like to define core requirements, and test requirements, and docs requirements, ot whatever.

but then, when someone want all that, they have to do something like:

conda install --file conda_requirments.txt --file conda_requirements_test.txt ...

etc...

So if we could have a pre-commit hook that builds a conda_requirements_all.txt file every time, then it's easy to maintain.

Does pre-commit-ci support that kind of thing?

[ocefpaf]

Does pre-commit-ci support that kind of thing?

You'll probably have to write your own pre-commit for that, then plug it into pre-commit-ci.

I would argue to drop all those files and just use pixi.

[ChrisBarker-NOAA]

pixi's fine with me, and for the development process, but others do need a non-pixi conda option.

Though I suppose we could just give them one all config ...

But maybe later, in any case.

[ocefpaf]

pixi's fine with me, and for the development process, but others do need a non-pixi conda option.

Most conda users will know what to do with the pyproject.toml. Multiple files may diverge and increase the maintainace burden. Note that conda will support pixi lockfile soon, which would be the easiest way to cover that use case.

[ChrisBarker-NOAA]

Most conda users will know what to do with the pyproject.toml

no, they won't. :-(

Multiple files may diverge and increase the maintenance burden

which is why I want to automate it -- we could even build a conda requirements file from the pyproject.toml.

Note that conda will support pixi lockfile soon, which would be the easiest way to cover that use case.

That would be great -- yes. So maybe not bother with another solution is this is coming soon.