Review dependencies

[gregurco]

Q	A
Bug fix	no
New feature	no
BC breaks	no
Deprecations	no
Tests pass	yes
Fixed tickets	#172
License	MIT

What I did:

• added assets:install command in readme, because sometimes this command is not performed automatically and we should provide information about that.
• added symfony/framework-bundle in dependencies, because there are some features that bundle uses. For example assets function for this is defined there and also command assets:install. And as I see, many bundles are dependent on this package.
  • removed symfony/dependency-injection, symfony/event-dispatcher, symfony/http-kernel and symfony/config because these packages are provided by symfony/framework-bundle.

Merry Christmas :christmas_tree: :snowflake: :slightly_smiling_face:

[florianpreusner]

I'm not sure if it's a good idea to remove dependencies cause they are provided by another one. What happens if symfony/framework-bundle changes that? Than our bundle is not able to work anymore. What's your opinion, @gregurco? I would suggest to add all dependencies even if they are provided by another lib. So we can also make sure to use specific versions, if required.

[gregurco]

@florianpreusner usually when I have such a question, I open packagist, search for top bundles and watch examples from them :slightly_smiling_face: I observed 2 approaches: with all dependencies listed (friendsofsymfony/rest-bundle) and with symfony/framework-bundle + some additional packages not related to the first one (nelmio/api-doc-bundle, jms/serializer-bundle and many others). I think that framework-bundle is trustable enough and composer.json became more clean but yep, we can add all dependencies like fos team did. What do you think? Do we trust framework-bundle or not? :smile:

[florianpreusner]

Well, I do trust framework-bundle but it's more a concept for me. When we decide to remove dependencies in our bundle because they are defined in framework-bundle and the only reason is, that it's a official symfony bundle than I would suggest to keep the dependencies in composer.json. Cause that would be a strange rule, or?

I mean, if every dependency is really following semantic versioning there should be no problem.

[florianpreusner]

If I would start a new plain php project I would define all dependencies that I use. Just to make sure that I have specific versions. And maybe because I do not trust every dependency 😆 .

I can live with both ideas. You have done a lot in the past, @gregurco. And you are a clean coder. So it's up to you.

[gregurco]

@florianpreusner let's try to merge this version of composer.json. We will be in the majority with this mode of dependencies and guess symfony core team takes care of FrameworkBundle and doesn't want to break the whole symfony ecosystem :slightly_smiling_face: And I think we can do new release when will be sure in all changes, because there are many changes not released yet :slightly_smiling_face:

[florianpreusner]

Released in v7.3.0 (https://github.com/8p/EightPointsGuzzleBundle/releases/tag/7.3.0)