30KLoC in 149 modules a microframework does not make.
Hmm, perhaps we aren't measuring the same thing, or are measuring tests and
test modules, but I'm not getting the same numbers as you. But I also think
KLoC is a terrible measure of anything important, so I'd be much more
concerned about actual code quality issues. Oh, and while writing this I
see that Chris has posted actual numbers, which for those who want the data
seems much more sensible than the above.
> Especially when it re-implements template engine adaptors (alacarte),
> session handling (Beaker), configuration file parsing (PasteDeploy), thread
> locals (Paste), has a large amount of authentication/authorization code to
> adapt repoze.{who,what} (a package I recall people saying was a mistake to
> make required for TG2.0), object dispatch (crank), regex-based routing
> (Routes), static file serving (Paste), etc. The majority of these are
> modules contained within one package and thoroughly blended.
>
Chris and ben have covered the details of this much more extensively than I
will, so I'll content myself to saying something at the top philosophical
level. Ss far as keeping things in one package, I'm not as opposed to that
as you are.
While there is value in pulling modules out into separate packages, there is
also a lot of value in reducing the complexity of the package dependency
graph. (Trust me, that this has been a huge problem in TG2 release
processes!)
There is certainly a balance to be found, but I've gone down the thousand
little packages path, and it's not at all perfect -- changes in one place
can break code in another, and integration testing can be a real nightmare.
> All of this needs testing and documentation, all of which would be more
> useful as reusable, and more importantly, optional components. Most are
> already available as reusable components. From the standpoint of a template
> engine developer I have to write adapters for two widget systems, at least
> one framework (probably more), and still have my own API to deal with. As a
> framework user, if I want to use a templating engine that’s new -I- have to
> write the adapters. The duplication of work is horrendous.
>
Optional does not necessarily mean separate package. And honestly, I don't
so much care about making *everything* optional, I just want people to be
able to swap out defaults for alternatives when the alternatives are better
for them in a real way. I'm not sure that this will *ever* be true of
configuration systems.
For template configuration, I'm not opposed to a standard interface, but I
think that what's needed is a well defined interface, not a "common template
adapter package." Of course such a package might be valuable given that
there is not yet such a standard interface. And perhaps we should use such
a third party package, clear arguments for why we should, particularly when
coupled with code will certainly be listened to eagerly.
> TurboGears 3, or the future project with no name yet, doesn’t need Pyramid
> from a technical standpoint. It didn’t need Pylons. WebCore showed that
> utilizing the same components as TurboGears (PasteScript, PasteDeploy,
> Genshi/Mako, ToscaWidgets, Beaker, SQLAlchemy, etc.) without a parent
> framework can be trivially easy, modular, light-weight, and fast. Relying
> on another ‘base’ framework seems to me to be a repeat of past mistakes,
> with more pitfalls than benefits.
Of course we don't NEED them. Nor do we need WebCore or whatever, we could
do it ourselves. That is definitely one of the options on the table. But
going our own way has it's own costs, which are significant. And working
with others, has benefits which are significant.
IMHO, what we NEED is to keep and maintain a critical mass of committed
developers that will move the framework forward, and will help us to be
competitive in the market.
We've had lots of developers go on to create their own frameworks, or do
other things, and IMHO that's good. It shows the options, and helps us see
ourselves better, but it doesn't make TG more viable. What makes us more
viable is a core team of people who work together to improve the framework,
and are committed to the project and the team.
I don't at all begrudge your right to do other things. And more than that,
I respect your right to do them, and appreciate the passion, and intensity
that have gone into WebCore and related projects, as well as the quality
code that has come out of those projects.
I really do appreciate your feedback. I know it can be hard voice an
opinion that's likely to be unpopular.
I may not agree with everything you've said. You start out blaming us for
being prejudiced against your approach, so I think it's only fair to point
out that I point out that there may be a few in your jump to conclusions,
about pyramid as well. At the same time I'm sure the same is true for me,
and I've probably jumped to conclusions here too, so I'm definitely going to
spend some time thinking about the issues you raised.
And thanks again for your feedback on this. And I too look forward to what I
hope is a bright future for all of our projects, whatever decisions end up
getting made.
--Mark Ramm
--
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en.
