During the weekly Symfony meeting yesterday, we talked about third-party
dependencies in the framework in general, and more specifically in
components. No consensus was found, and so we decided to not decide
anything. After this meeting, Johannes, Bernhard, and myself exchanged
some emails on the topic. Why the three of us? Because Johannes manages
the security component (and it has a dependency on Doctrine DBAL for
ACL), and Bernhard manages the form/validator components (and they have
an optional dependency on Doctrine). As the developers in charge of the
maintenance of these components, we have of course a rather strong
opinion on how things need to be done.
As we don't believe that we can make everyone happy, here is what we
think is the best for the project:
The Component sub-namespace hosts libraries that can be used standalone.
They *must* not have any mandatory externals dependencies (they can
however have limited mandatory dependencies on other Symfony2 components
-- like Form and Validator for instance).
For some features, components *may* have optional dependencies on
third-party libraries that we, as the Symfony core team, support (as of
today, it mostly means Doctrine, Swiftmailer, and Twig).
The goal is to make the components as useful as possible when used
outside the Symfony2 context. So, if someone wants to use the Security
component without the Symfony MVC framework, he should be able to do so.
Of course, if he uses Propel, and not Doctrine, he is on his own. But if
he uses Doctrine, he has a complete and working package that works
standalone.
Although we implement support for certain dependencies ourselves, there
is (and must be) a clear interface that allows to replace it by custom
implementations.
So, what about the Propel guy then? As we don't have a Propel bundle, it
changes nothing for him. We don't have support in the component, but we
don't have support in the framework either. Of course, people willing to
contribute support for other libraries (like Propel, Zend Mailer, or
Smarty for instance) can do so in a Bundle, in the library itself, or in
yet another "tie-in" library that they distribute themselves. But that
won't be part of the core framework.
We think this is the best compromise we can find.
P.S.: I will only merge Bernhard pull request after we settle on a strategy.
--
Fabien Potencier
Sensio CEO - Symfony lead developer
sensiolabs.com | symfony-project.org | fabien.potencier.org
Tél: +33 1 40 99 80 80
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
