sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='nul' mode='w' encoding='cp932'>

[AkiraRy]

TL;DR

I don't know if it is weaviate's fault but i figured out i should make an issue nevertheless. Simply running a file containing those 2 imports will reproduce this bug on my machine. Anywhere, doesn't even need to be in a project. I don't really know how can i trace the actual file which leaves an open connection. Any help will be greatly appreciated.
I'm not sure which library's fault this is but i submitted issues to llama-cpp-python and here.

How to reproduce this bag?

import llama_cpp as llm
import weaviate

What is the expected behavior?

Libraries simply load without any warnings.

What is the actual behavior?

When I load those 2 libraries together I get this warning
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='nul' mode='w' encoding='cp932'>

Supporting information

I use conda to manage libraries.
weaviate-client=4.9.3
llama-cpp-python=0.3.1
python=3.11.10

[tsmith023]

Hi @AkiraRy, we recently refactored the underlying connection for the sync/async clients and I think this issue may have been fixed by the refactor. Can you try using v4.13.0 and confirm whether you're still seeing the warning? Cheers!

[dudanogueira]

Hi @AkiraRy — I dug into this and the leaked file handle isn't coming from weaviate-client. Quick reproduction on a current build (post-v4.13 refactor):

imports	unclosed-file warnings
import weaviate only	0
import llama_cpp only	2
both (either order)	2

So import weaviate adds nothing — llama_cpp is leaking the two handles on its own, and putting weaviate on the same line just made it look related.

The source is in llama-cpp-python's _utils.py:

# Avoid "LookupError: unknown encoding: ascii" when open() called in a destructor
outnull_file = open(os.devnull, "w")
errnull_file = open(os.devnull, "w")

Two module-level open(os.devnull) calls — these are deliberately kept open for suppress_stdout_stderr to redirect C-level stdout/stderr, and never closed (the comment explains why: they're used from __del__, where the codecs registry may already be torn down). On your Windows + JA-locale setup the warning surfaces as name='nul' ... encoding='cp932'; on macOS it surfaces as name='/dev/null' ... encoding='UTF-8' — same root cause, just platform defaults.

I'd suggest tracking this on the abetlen/llama-cpp-python side — closing this one out. Thanks for the report!

[AkiraRy]

Hey @dudanogueira, thanks a lot for your investigation and time, but I'm not sure it was worth digging into a 2y old problem 😄