test_issue_1089 should not assume a low NO_FILE limit

[booxter]

Describe the bug

A clear and concise description of what the bug is.

The test case iterates over the number of allowed files to open, doing work. Then checks that the test suite survived. The problem is that the test case assumes that the soft limit for the allowed files to open is "reasonably" low. When I run the suite on my Darwin machine where it's 1048576, the test never completes.

This can be worked around by setting the limit to something "reasonable" with ulimit -n 1024. But this is a workaround, and the test suite should not include test cases that rely on platform specific settings. I'd think there are better ways to confirm that leaks are not happening, e.g. the test case could check that the number of currently opened files doesn't grow drastically, whatever it means.

Have you tried repairing the PDF?

Please try running your code with pdfplumber.open(..., repair=True) before submitting a bug report.

Code to reproduce the problem

Paste it here, or attach a Python file.

PDF file

Please attach any PDFs necessary to reproduce the problem.

If you need to redact text in a sensitive PDF, you can run it through JoshData/pdf-redactor.

Expected behavior

What did you expect the result should have been?

Actual behavior

What actually happened, instead?

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

• pdfplumber version: 0.11.5
• Python version: Any (python3.11 or python3.12, doesn't matter)
• OS: Darwin (but really, can be any platform because limits are not OS-dependent)

Additional context

Add any other context/notes about the problem here.

[jsvine]

Thank you for this bug report. I'll look into modifying that test case.