Nah, requiring Symfony is like requiring Django. Doesn't make much sense.

It's actually Silex. Maybe that makes more sense.

Silex is hardly a "micro framework", it's basically Symfony without the configuration files. So it's a LOT of code. I like it by the way, always hated the Spring like insanity of Symfony, but let's not pretend Silex + all Symfony libs the framework has to import are small.

The irony is that for this very project, Both Silex and Symfony\Process are completely redundant, especially with PHP bloated core APIs.

That's not correct. Silex replaces the Symfony DI (or service locator, if you will) component with something much simpler called Pimple. You can read the code within a few minutes.

The only other required libraries for Silex to function are the event dispatcher, routing (which you can swap out for something like nikic/FastRoute), and the request/response stuff. I'm not sure if you think that's a "lot" of code, but if you're rolling your own you'd probably end up using the HTTPFoundation stuff anyway.

> That's not correct. Silex replaces the Symfony DI (or service locator, if you will) component with something much simpler called Pimple. You can read the code within a few minutes.

That's exactly what I said, what is the point of your message? With Silex there is no configuration through XML or YAML. What is not correct?

You ranted about it being a "lot" of code. The default Silex installation doesn't even bring in the Security component, which is probably what prompted your comparison to Spring.

Event dispatching + kernel (basically a handler) + request/response isn't particularly complex, is it?

But it's not requiring Symfony.