Skip to content

Fix local installation and wheel packaging (supersedes #59) - #77

Open
RewardGuard wants to merge 4 commits into
Farama-Foundation:mainfrom
RewardGuard:fix-local-install
Open

Fix local installation and wheel packaging (supersedes #59)#77
RewardGuard wants to merge 4 commits into
Farama-Foundation:mainfrom
RewardGuard:fix-local-install

Conversation

@RewardGuard

Copy link
Copy Markdown
Contributor

Description

Supersedes #59 (which had merge conflicts with main). Rebased cleanly on current main and reworked so it is correct and verified on macOS as well as Linux/Windows.

pip install -e . (and, in fact, wheel packaging) was broken: the CMake/make build emits a generically-named shared library (libmagent.dylib / libmagent.so / magent.dll), but setuptools expects the extension at the interpreter-specific path from get_ext_fullpath() (e.g. magent2/libmagent.cpython-312-darwin.so). Nothing copied the build output there, so editable installs failed with can't copy '.../libmagent.cpython-312-darwin.so': doesn't exist and built wheels shipped without a loadable library.

Changes

  • setup.py — after the platform-specific build, locate the produced library (via a small helper that also handles multi-config generators like MSVC's Release/ subdir) and copy it to get_ext_fullpath(ext.name). Also raise on unsupported platforms instead of silently falling through.
  • magent2/c_lib.py — load the library from the same EXT_SUFFIX-based name (libmagent<EXT_SUFFIX>) on every platform, so the loader and the packaged file always agree. This removes the previous per-OS hard-coded filenames.

Unlike #59, this works on macOS too: #59 loaded libmagent.<SOABI>.dylib while setuptools produces a ...darwin.so file, so the names didn't match on macOS. Deriving both sides from EXT_SUFFIX keeps them consistent everywhere.

Verification (macOS, CPython 3.12)

  • pip install -e . — succeeds, C library loads, environments run.
  • pip wheel . — wheel contains magent2/libmagent.cpython-312-darwin.so.
  • Fresh install of that wheel + pytest tests2 passed.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

🤖 Generated with Claude Code

Gio and others added 4 commits July 13, 2026 10:14
The CMake/make build emits a generically named shared library
(`libmagent.dylib` / `libmagent.so` / `magent.dll`), but setuptools expects
the extension at the interpreter-specific path returned by
`get_ext_fullpath()` (e.g. `magent2/libmagent.cpython-312-darwin.so`).
Because nothing copied the build output to that path, `pip install -e .`
failed with "can't copy ... doesn't exist" and wheels shipped without a
loadable library.

- setup.py: after the platform build, locate the produced library (handling
  multi-config generators) and copy it to `get_ext_fullpath(ext.name)`. Also
  raise on unsupported platforms instead of silently continuing.
- c_lib.py: load the library from the same EXT_SUFFIX-based name, so the
  loader and the packaged file always agree across platforms.

Verified on macOS: `pip install -e .`, `pip wheel .`, a fresh wheel install,
and `pytest tests` (2 passed) all succeed.

Supersedes Farama-Foundation#59.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants