Slim: Remove built-in container and Pimple dependency

[codeguy]

The DIC will become 100% optional. Slim will no longer provide its own default container, and we can remove the dependency on Pimple.

We'll need to migrate the built-in object dependencies elsewhere, perhaps the built-in HTTP decorator classes.

[geggleto]

I'm not a fan of this as the PHP ecosystem has no standard way for registering services. 👎

[mnapoli]

Having written a PHP-DI integration I'm interested by this change, but I think that users should not be left by themselves to use a container.

For what it's worth here is what I did with Silly's documentation:

Slim could have a documentation for DIC + list of supported containers (like Zend Expressive). Whether those would be external links or internal docs is a detail, I'm 👍 to write some documentation for PHP-DI if that's of any interest.

And by "supported containers" I mean what @geggleto means: containers that have the default services registered.

I'm not a fan of this as the PHP ecosystem has no standard way for registering services.

Maybe you could have a look at https://github.com/container-interop/service-provider ? It has been WIP for some time but it's getting more and more stable. With a final push we could make a 1.0 and it could benefit Slim, just like with container-interop? Also that solution is so simple it is extremely easy to support in any DIC so it would be an improvement from the current DefaultServicesProvider.

[geekish]

And by "supported containers" I mean what @geggleto means: containers that have the default services registered.

+1 for this. Especially since I _just_ released Slimbox.

[moufmouf]

Maybe you could have a look at https://github.com/container-interop/service-provider ? It has been WIP for some time but it's getting more and more stable. With a final push we could make a 1.0 and it could benefit Slim, just like with container-interop?

Completely agree with @mnapoli . What Slim needs is a way to put its services into any container. As long as this is not possible, Slim will have to provide packages with pre-configured containers (like Slimbox). You should definitely have a look at https://github.com/container-interop/service-provider since this will solve this issue for all containers. This is still work in progress. We are currently working on passing PSR-11. As soon as this is done, work on container-interop/service-provider will start again and we are quite close to a 1.0. Also, any help is welcome :)

[geggleto]

Theory Code

$dic = \Some\Container(); //implements ContainerInterop

$app = new \Slim\App(); //Slim maintains all of its own components

$app->setDIC($dic); //DIC required for Class:method route calls, otherwise slim calls it with a no-argument constructor

$app->setResponseFactory(new ResponseFactory());

$request = (new RequestFactory())->buildFromGlobals();

$response = $app->run($request);

print (new Render())->output($response);

[akrabat]

Not totally sure about the factories, but theory code doesn't look too far out of left field.

[geggleto]

@akrabat as I mentioned in another issue, w/o the factories I am not sure how we can fully decouple from our own PSR-7 implementation. The factory approach was the only one I could come up with.

[akrabat]

Where would Slim use a Response object? The new ErrorMiddleware?

[akrabat]

Ah. Are you thinking about helping users create Response-independent middleware?

[geggleto]

@akrabat Yes :)

[ghost]

Why not using an automatic dependency injection, auto dependency resolution instantiation ? like https://github.com/rdlowrey/auryn

[codeguy]

@0x13a Slim will continue to support third-party containers that implement the container-interop interface. But Slim will not provide it's own built-in container.

[akrabat]

Fixed by #2290

[trasher]

It seems that Silex (and probably Pimple as well) will reach its EOL in 2018; so this is a good news Slim no longer rely on it :)

[odan]

Hi @trasher Pimple is not dead and still alive.

Here is a statement from fabpot: https://github.com/silexphp/Pimple/issues/243

[trasher]

Ha ok :) I've read the project was looking for a new maintainer some months ago... Did not know they've find one.

Anyways, not relying on pimple is still a good thing ;)