Fix macOS wheel: Exclude falkordb.so from virtualenv bin/ with broken @loader_path

[Copilot]

macOS wheels installed falkordb.so to both site-packages/redislite/bin/ (correct) and virtualenv/bin/ (broken). The bin/ copy had @loader_path/../../redislite/.dylibs/ references that resolved outside the virtualenv, causing dlopen failures in pytest and other contexts.

Root Cause

InstallRedis.run() called copy_tree(build_scripts, install_scripts), copying all files including the shared library to virtualenv's bin/. When delocate-wheel processed the wheel, it fixed paths for redislite/bin/falkordb.so but the data/scripts/ copy (→ bin/) retained broken references.

Changes

• Replace copy_tree() with selective copying of executables only (redis-server, redis-cli)
• Exclude falkordb.so from install_scripts entirely—shared library now exists only in redislite/bin/
• Add INSTALL_BIN_EXECUTABLES constant and missing executable warnings for maintainability

# Before: copied everything including shared library
self.copy_tree(self.build_scripts, self.install_scripts)

# After: copy only standalone executables
for executable in INSTALL_BIN_EXECUTABLES:
    src = os.path.join(self.build_scripts, executable)
    dst = os.path.join(self.install_scripts, executable)
    if os.path.exists(src):
        self.copy_file(src, dst)

Result

• virtualenv/bin/: redis-server, redis-cli (no falkordb.so)
• site-packages/redislite/bin/: redis-server, redis-cli, falkordb.so (with correct @loader_path/../.dylibs/)

Linux wheels and editable installs unaffected.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[CRITICAL] macOS wheel installs falkordb.so to bin/ with broken @loader_path references</issue_title>
<issue_description>macOS wheel for v0.4.0 includes falkordb.so in data/scripts/ which gets installed to the virtualenv's bin/ directory. The copy has incorrect @loader_path references that fail to resolve, causing dlopen failures during import in certain execution contexts, specifically pytest for me. This results in buggy code that sometimes works in-app but breaks in pytest and vice versa.

For a sanity check, I looked at RECORD:

../../../bin/falkordb.so,sha256=XGgCTiBufWuekEeqA4dsEzayI7QiFvET4kS_1j8Gjzg,22062912
redislite/bin/falkordb.so,sha256=Ij3-7ld8inlJGH1jkmv9ePlpTY8V59RGGjeMpalj91A,22062912

Two different SHA256 hashes, two different files with different embedded paths.

My env:

• falkordblite version: 0.4.0
• Platform: macOS (tested on Darwin 24.6.0, arm64)
• Python: 3.13.8
• Wheel: falkordblite-0.4.0-cp313-cp313-macosx_10_13_x86_64.macosx_15_0_arm64.whl

To reproduce:

# Create fresh virtualenv and install
uv venv .venv
uv pip install falkordblite==0.4.0

# Verify broken file exists
otool -L .venv/bin/falkordb.so | grep @loader_path
# Output shows: @loader_path/../../redislite/.dylibs/libomp.dylib

# Import fails in certain contexts (e.g., pytest)
# Error: dlopen(...): Library not loaded: @loader_path/../../redislite/.dylibs/libomp.dylib

The wheel contains two copies of falkordb.so with different @loader_path references:

1. redislite/bin/falkordb.so [correct]

@loader_path/../.dylibs/libomp.dylib
@loader_path/../.dylibs/libssl.3.dylib
@loader_path/../.dylibs/libcrypto.3.dylib

2. falkordblite-0.4.0.data/scripts/falkordb.so [BROKEN]

@loader_path/../../redislite/.dylibs/libomp.dylib
@loader_path/../../redislite/.dylibs/libssl.3.dylib
@loader_path/../../redislite/.dylibs/libcrypto.3.dylib

The data/scripts/ version is installed to .venv/bin/falkordb.so. From that location, the path @loader_path/../../redislite/.dylibs/ resolves to a location outside the virtualenv, where no libraries exist. When Python's dynamic loader encounters the broken .venv/bin/falkordb.so before the correct site-packages/redislite/bin/falkordb.so, the import fails:

RuntimeError: FalkorDB Lite is unavailable

Caused by:
dlopen(.venv/bin/falkordb.so): Library not loaded: @loader_path/../../redislite/.dylibs/libomp.dylib
  Reason: tried: '.venv/bin/../../redislite/.dylibs/libomp.dylib' (no such file)

This particularly affects pytest where cwd and import order can differ from direct Python invocation.

To work around this, I just delete the broken binaries after installation:

rm .venv/bin/falkordb.so .venv/bin/redis-cli .venv/bin/redis-server

but that's obviously not ideal.

For a proper fix, I suggest removing falkordb.so from data/scripts/ entirely. If it's not a standalone CLI tool, it's a shared library that should only exist in redislite/bin/. If CLI exposure is intentional, you can fix the @loader_path references during wheel build with install_name_tool:

install_name_tool -change \
  "@loader_path/../.dylibs/libomp.dylib" \
  "@loader_path/../lib/python3.X/site-packages/redislite/.dylibs/libomp.dylib" \
  data/scripts/falkordb.so

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim FalkorDB/falkordblite#27 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @flavius-popan (replace 20 with the amount, and @flavius-popan with the user to tip).

📖 If you want to learn more, check out our documentation.

Comments on the Issue (you are @copilot in this section)

• Fixes [CRITICAL] macOS wheel installs falkordb.so to bin/ with broken @loader_path references #27

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}