On Fri, Mar 4, 2011 at 9:39 AM, Chris McDonough <chr...@plope.com> wrote: > Of these, the only ones to very easily *not* install would be Mako, > Chameleon, PasteScript, Paste, and PasteDeploy. The others are core > dependencies that really can't very easily be externalized. > > Doing that would take us down to 13 dependencies. We could indeed make > "pyramid_chameleon" and "pyramid_mako" and "pyramid_paste" packages to > restore the functionality for users of those dependencies. > > Would that actually service any particular goal? Would having fewer > "rails" in the core actually make anybody happier?
I was -1 on splitting them but as I thought about it more I'm +0. There's a benefit in distinguishing more between what Pyramid itself needs and what the application templates need. If somebody is never going to use Chameleon or Mako, or they detest PasteDeploy, why install them? Especially if it causes problems in space-constrained deployments. The user can't nullify a dependency without changing other packages' setup.py files, and excluding packages manually that then get re-added whenever somebody runs "python setup.py install" because they think it will just bring the app up to date seems wrong. If we do split them off, we should probably add a paragraph to the templates' documentation saying "this template uses X which provides X", or "all templates distributed with Pyramid depend on X which provides X". That will keep people fully informed about what decisions the templates are making for them, and what leeway they have to choose alternatives. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
