Exclude Pipfile.lock from pretty-format-json pre-commit hook

[jsf9k]

🗣 Description

This pull request modifies the pre-commit configuration to exclude Pipfile.lock from the pretty-format-json hook.

💭 Motivation and context

We will simply let pipenv format those files however it wants; we don't care about prettifying them since they are for the most part only read by machines. This also saves us some time and effort on Dependabot PRs that update the Pipfile.lock file since they should pass the pre-commit linters without being reformatted.

🧪 Testing

All automated tests pass.

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• All relevant type-of-change labels have been added.
• I have read the CONTRIBUTING document.
• These code changes follow cisagov code standards.
• All new and existing tests pass.

[dav3r]

🎉

[dav3r]

@mcdonnnj Can you please review this change? It will make our lives easier with all of the dependabot PRs that currently fail linting.

[mcdonnnj]

Is there any reason this shouldn't be baked into the base configuration housed in cisagov/skeleton-generic?

[dav3r]

Is there any reason this shouldn't be baked into the base configuration housed in cisagov/skeleton-generic?

The only argument against that is it's not really necessary since we don't have pipfiles in skeleton-generic. I seem to recall we had another similar situation in the past, but I don't recall which way we went with it. I'm fine either way.

[mcdonnnj]

Is there any reason this shouldn't be baked into the base configuration housed in cisagov/skeleton-generic?

The only argument against that is it's not really necessary since we don't have pipfiles in skeleton-generic. I seem to recall we had another similar situation in the past, but I don't recall which way we went with it. I'm fine either way.

I think that since we would make use of this in at least two descendant skeleton projects, and since it has no negative impact, we should punt it up to the base configuration in cisagov/skeleton-generic.

[dav3r]

Is there any reason this shouldn't be baked into the base configuration housed in cisagov/skeleton-generic?

The only argument against that is it's not really necessary since we don't have pipfiles in skeleton-generic. I seem to recall we had another similar situation in the past, but I don't recall which way we went with it. I'm fine either way.

I think that since we would make use of this in at least two descendant skeleton projects, and since it has no negative impact, we should punt it up to the base configuration in cisagov/skeleton-generic.

That logic works for me. @jsf9k, unless you have major objections, can you please make a PR for this in skeleton-generic and then close this one out?

[jsf9k]

The only argument against that is it's not really necessary since we don't have pipfiles in skeleton-generic. I seem to recall we had another similar situation in the past, but I don't recall which way we went with it. I'm fine either way.

Won't the check-useless-excludes pre-commit hook fail if nothing matches the regex?

[dav3r]

The only argument against that is it's not really necessary since we don't have pipfiles in skeleton-generic. I seem to recall we had another similar situation in the past, but I don't recall which way we went with it. I'm fine either way.

Won't the check-useless-excludes pre-commit hook fail if nothing matches the regex?

That is a good point. @mcdonnnj Any thoughts?

[mcdonnnj]

The only argument against that is it's not really necessary since we don't have pipfiles in skeleton-generic. I seem to recall we had another similar situation in the past, but I don't recall which way we went with it. I'm fine either way.

Won't the check-useless-excludes pre-commit hook fail if nothing matches the regex?

That is a good point. @mcdonnnj Any thoughts?

He is correct and I completely forgot about that hook. I guess the only alternative thought I had was adding the exclude but commenting it out until needed. Basically treating it similar to dependabot ignore statements that we enable downstream, but in this case enable as needed. I just like the idea of storing a configuration detail used across multiple skeleton lineages in a single place.

[jsf9k]

I guess the only alternative thought I had was adding the exclude but commenting it out until needed. Basically treating it similar to dependabot ignore statements that we enable downstream, but in this case enable as needed. I just like the idea of storing a configuration detail used across multiple skeleton lineages in a single place.

For the love of JVPITER! Closing this PR in favor of cisagov/skeleton-generic#261.