On 28.01.2011, at 10:33, Fabien Potencier wrote: > 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.
+1 regards, Lukas Kahwe Smith [email protected] -- 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
