I'm not really convinced this is a good idea. there's literally zero reason to block read only access to sysconf. I think cursor should fix their broken setup instead

not to mention if sysconf is blocked I can't imagine what else is blocked and I don't expect pre-commit to get any further

plus I can't accept ai generated patches and it's super clear this was not written by you

Thanks for your swift response. I had hoped for a few days (or weeks), but got a response in a fewminutes. Thanks.

This was my largest attempt at patching such a public repo, so I'd appreciate some assistance to understand what I cold have done differently to propose a change that would have worked for you.

BTW.... I invested time in this patch because I found pre-commit hooks to be so helpful. I was at the point of having to decide whether to drop pre-commit or Cursor. It was tough. I wanted to use them BOTH. I've been involved with open source for decades. I figured I could make a difference here much easier than with OpenAI. ;-}

Since the issue was triggered by a single line in pre-commit, I started there.

It worked. The proposed change allows me to continue using pre-commit in a repo that has code I've been maintaing for about 20+ years -- my personal profile that works across many systems.

I can now ask Cursor to "analyze and commit", and it will create a commit message for staged changes, then commit (including pre-commit hooks).

I was actually doing a happy dance to celebrate this win when I received your comments.

Let me see if I can address each of them...

I'm not really convinced this is a good idea. there's literally zero reason to block read only access to sysconf. I think cursor should fix their broken setup instead

I can't speak to their reasons for blockingsysconf, but my research convinced me that lead me to believe that POSIX_MAX_ARG is a safe default foros.sysconf('SC_ARG_MAX'), both at load-time and also at run-time. Do you agree?

not to mention if sysconf is blocked I can't imagine what else is blocked and I don't expect pre-commit to get any further

I guess I don't understand what this is pointing at. I only researched the problems that arose with os.sysconf(). There was only one
os.sysconf('SC_ARG_MAX')

Once this was overcome, pre-commit got much further. All the way.. It completed beautifully.

plus I can't accept ai generated patches and it's super clear this was not written by you

This PR was my work. Human research. Human review. Human testing. Human experience.

AI was my assistant, not the leader. This was NOT vibe coding.

I started with background research. Then we generated a failing test that would showcase the issue. Only then did I modify the original code.

Generating the code was actually the easy part. I could have done that in significantly less time, but I wanted the test (and the understanding behind it) to give me the confidence that it was a robust change. I'm happy to have had AI to assist me. I'm especially grateful that it pointed out a problem with my testing strategy allowedconftest.py that peventedpytest from even running my tests.

TL;DR; -- I submitted this work because I value what pre-commit does for me. It was my work. Human work. Human experience. Human caring.

It fixed my work-flow blockage. I think it could be helpful to othersj, too.