2008/9/17 Mark Ramm <[EMAIL PROTECTED]>: > As I mentioned you'll have to thank Jacob for that one -- he's the one > who asked me to do it, and encouraged me not to pull my punches, but > to say what I really thought.
Fair play. [snip] > Kevin Teague has a great blog post abut the package installation > infrastructure that's available in python. He pretty much charts all > the options. > > http://www.bud.ca/blog/pony > > Though I do think it might be worth mentioning in the context of > Django that you could do something like distribute a tarball with all > of the packages django needs included and a paver script that lets you > install all the django dependencies before you install django itself. Yeah I saw that, and Jacob mentioned the egg tarball option. >> 2008/9/17 Simon Davy <[EMAIL PROTECTED]>: >> Two things I learned that Django does better than TG/Pylons, IMO: >> >> Style: >> >> Django stuff looks good. The culture in Django is more design >> orientated than TG, and I think that is a factor in their success. At >> PyCon UK, Stephen Emslie demo'd a nice interactive WSGI profiler >> module[1], and one the Django folk's comments was "Sweet! But you >> Pylons guys always make things so ugly - get a designer to give you a >> style sheet already". They have a point IMHO. > > Well, we need to attract more designers ;) But seriously, this is a > point well taken, and we're trying to improve the out of the box > design experience for many TG related projects. And in the > particular case of the WSGI profiler, I think that Armin may be > getting involved, and he has some design sense. Hmm, I might try getting some designer friends interested in contributing... >> Apps: [SNIP] >> RUM is likely the way forward here - if we write things to the RUM >> Factory apis[2], controller/model interactions can be abstracted to >> allow plugin apps to work with any stack component, in theory. > > One that TurboGears exists, is that we want to allow people to write > plugin apps that assume the existence of SQLAlchemy, can be mounted > easily by instantiating an object, and can assume that you have other > necessary components like Beaker sessions, automatic cross-database > transactions, genshi, mako and/or jinja. Fair enough, but all the Django apps "assume" you have the django stack, so we're not getting any closer to app reuse between frameworks (which may be an ambitious goal, I agree) > I think it would be interesting to create some of those plugins > towards the RUM data abstraction layer, but I don't at all think it's > necessary for most pluggable apps -- a very large majority of our > users are going to be using SQLAlchemy. And if they aren't we can > still use SA in plugins and have the transaction manager manage the > interactions between the plugin database commits and the ones that the > app does itself. I didn't realise SA could do that, but that might go a long way to solving the problem. SA is great, as 99% agree, but if we start assuming it for the TG/Pylons app ecosystem, we could very quickly end up like Django - all that functionality lost unless you use a particular stack (in the case SA). Having said that, at least we're only building to the ORM, not the entire view/controller/middleware stack. And who doesn't use SA, really (he says as his SQLObject TG1 apps soldier on...)? -- Simon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
