- What does kachkaev/php-r-bundle do?
- It is a Symfony bundle that registers the framework-agnostic kachkaev/php-r library in the Symfony dependency injection container and configures the R executable plus runtime options. It lets Symfony code invoke R scripts and receive results back in PHP. It does not embed an R interpreter; it shells out to Rscript and parses stdout, so it follows a process-per-call model. The bundle layer itself is only Symfony wiring.
- Can I use kachkaev/php-r-bundle in a Laravel application?
- Not directly. The package is a Symfony bundle and ships no Laravel service provider, facade, config publisher, or contract, so Laravel will not auto-discover or boot it. In a Laravel codebase the bundle layer is dead weight, and all usable value sits in the underlying kachkaev/php-r library. You would ignore the bundle and either depend on php-r or write a small wrapper around Laravel's Process facade.
- How do I install kachkaev/php-r-bundle?
- You would normally install it with Composer and enable the bundle in a Symfony kernel, but its composer.json targets Symfony 2.x/3.x and PHP 5.5 to 7.x era constraints. It will not resolve cleanly against Symfony 4+ or modern Laravel dependency graphs without ignore-platform-reqs hacks or a fork. You also need an R runtime installed with the Rscript binary available in every environment.
- Which Laravel and PHP versions does this package support?
- None officially. There is no Laravel integration at all, and the bundle's constraints target Symfony 2/3 and older PHP versions. It has had no PHP 7.4 or 8.x compatibility work and no Symfony 4/5/6/7 support. Treat any claim of Laravel 9, 10, or 11 support as unsupported.
- How do I configure the R executable path?
- In Symfony the bundle exposes configuration for the R binary and runtime options through its Configuration tree and extension class. In Laravel you would not use that config; instead set an environment variable such as R_BINARY and pass it into your own process wrapper. Always use an absolute path to the Rscript binary so behavior does not depend on the web user's PATH.
- Is it safe to run R scripts from PHP in production?
- The underlying library shells out through exec or proc_open, so any user-influenced value passed into an R invocation is a command-injection risk unless every argument is escaped and scripts are addressed by absolute path. The project was archived in 2017 and receives no security patching, so any CVE in its transitive tree is yours to fix. Exit-code and stderr handling in this generation of php-r is weak, and failed R runs can surface as empty strings instead of exceptions. A safer pattern is running R behind plumber or Rserve and calling it over HTTP or a socket.
- What are the alternatives to this bundle for running R from Laravel?
- Use the kachkaev/php-r library directly behind a thin Laravel service provider, or skip it and call Rscript with Symfony Process or Laravel's Process facade in about forty lines. For anything request-path-critical, run R behind plumber or Rserve and call it with the HTTP client or a socket client. If the real asset is a trained model, export it to ONNX or PMML and score it in PHP or a Python service instead.
- Is kachkaev/php-r-bundle still maintained?
- No. The repository is archived, the last release was 2017-06-15, and it has roughly two stars and zero dependents. There is no active community, fork ecosystem, or Stack Overflow corpus to surface bugs. Treat it as a reference implementation for wrapping R invocation behind an interface, not as a production dependency.
- How should I test an R integration in a Laravel app?
- Unit-test your own wrapper by mocking the process runner and returning fixture stdout, so tests do not need R installed. Integration tests should run against a pinned Docker image that contains the exact R version and R package set, because R package versions drift independently of your Composer lockfile. Add explicit tests for non-zero exit codes and stderr, since older php-r behavior can return empty output rather than throwing.
- What is the performance and latency of running R through this bundle?
- Every call spawns a new R process, and R interpreter startup is typically around 100 to 500 milliseconds per invocation. That usually disqualifies per-request use in a PHP-FPM web tier and makes the pattern suitable only for batch scoring, reporting, or offline analytics. If you need sub-second interactive R, use Rserve or plumber with a persistent process instead.