You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
davidrjenni/scip-php:latest on Docker Hub also appears to predate the fix — pulled it today and Composer.php inside the image has no $cwd-based fallback (the exact logic src/Composer: fix $scipPhpVendorDir in case scip-php is installed as … #797 added), matching the pre-fix v0.0.2 source line-for-line.
What did you expect to see?
Following the README's own "Manual" install instructions:
The only install shape that actually works today is cloning main directly and running composer install inside that standalone checkout (so __DIR__-relative resolution — the original, pre-#797 code path — happens to succeed because the checkout is self-contained). That's not what the README documents, and isn't obvious to a new user hitting #235's crash on the "official" path.
Given #235 already has three separate users confirming the same crash on the Packagist-installed version, I'd guess this affects everyone following the README today, not just an edge case.
Would it be possible to cut a new Packagist release (or at least a Git tag) and rebuild the Docker image from current main, so #797's fix actually reaches users installing via the documented methods? Happy to help verify if useful — found this while wiring scip-php up as an optional SCIP indexer in an open-source code-intelligence MCP server (github.com/Eilodon/CALM) and wanted to report accurately rather than assume it was already covered.
Bug report
Link to repository
The bug is the exact one reported in #235 and fixed by #797 (merged 2026-03-28) — but that fix has apparently never reached a distributable artifact:
v0.0.2(published 2023-04-23): https://packagist.org/packages/davidrjenni/scip-php — predates src/Composer: fix $scipPhpVendorDir in case scip-php is installed as … #797 by ~3 years.davidrjenni/scip-php:lateston Docker Hub also appears to predate the fix — pulled it today andComposer.phpinside the image has no$cwd-based fallback (the exact logic src/Composer: fix $scipPhpVendorDir in case scip-php is installed as … #797 added), matching the pre-fix v0.0.2 source line-for-line.What did you expect to see?
Following the README's own "Manual" install instructions:
...to work, since #235 (the exact
RuntimeException: Invalid scip-php vendor directorycrash this produces) was already fixed by #797.What did you see instead?
The exact #235 crash, reproduced today via both documented install paths:
composer require --dev davidrjenni/scip-php(project-local) →vendor/bin/scip-phpcrashes.composer global require davidrjenni/scip-php→ same crash via the global bin.davidrjenni/scip-php:latestfrom Docker Hub and running it also crashes the same way (confirms the image is built from pre-src/Composer: fix $scipPhpVendorDir in case scip-php is installed as … #797 source, not currentmain).The only install shape that actually works today is cloning
maindirectly and runningcomposer installinside that standalone checkout (so__DIR__-relative resolution — the original, pre-#797 code path — happens to succeed because the checkout is self-contained). That's not what the README documents, and isn't obvious to a new user hitting #235's crash on the "official" path.Given #235 already has three separate users confirming the same crash on the Packagist-installed version, I'd guess this affects everyone following the README today, not just an edge case.
Would it be possible to cut a new Packagist release (or at least a Git tag) and rebuild the Docker image from current
main, so #797's fix actually reaches users installing via the documented methods? Happy to help verify if useful — found this while wiringscip-phpup as an optional SCIP indexer in an open-source code-intelligence MCP server (github.com/Eilodon/CALM) and wanted to report accurately rather than assume it was already covered.