-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 anatoly techtonik wrote: > On Sat, Sep 4, 2010 at 11:24 PM, osimons <oddsim...@gmail.com> wrote: >> It may just be ignored, of course... :-) Jokes aside, I'd be careful >> to put too much of this into Trac as it is not a core feature. Nice-to- >> have stuff for developers should really not be the primary focus - > > This is scary. Google App Engine is so popular, because it has nice > stuff for developers. If Trac had better dev. tools - it could have > bigger adoption and better coverage in blogs and more patches landing > on t.e.o. Needless to say that with proper tools trac-hacks would have > been already migrated to at least 0.11
Not quite comparable in my eyes, but I do understand your call for a more feature-full yet easier to install default distribution. Just recognize that this not necessarily requires integration of more plugins/functions into Trac core but well going further than just some recommendations of interesting, potentially valuable plugins on two not overly prominent wiki page [1][2]. You may want to join Ryan in his approach to build bigger and well maintained packages to ease on choice an installation effort [3]. Be brave and package i.e. say 20 not-to-miss Trac plugins, tested with version 0.13 side-by-side? Why not? Anyway I have reason to guess, all this is not as strongly related to Trac-Hacks.org still being on 0.10 as you suggest here, just another story. >> certainly when many decent alternatives exists. Most notably in the >> form of Wsgi middleware solutions from various libraries (like >> werkzeug) and standalone scripts. > > That makes Trac half-baked product that you must cook before use. The > abundance of installation recipes always was a annoyance for me. It is > good to have diversity, but the drawback of this is that you must be a > very advanced user and know all technologies to make the right choice. > You may, of course, just randomly choose some solution and follow > that, but tech-savvy people usually don't welcome that approach. This is certainly true and again should lead to constructive discussion on the matter. Of course not guaranteed to happen, since this is not about democracy here, but as I've seen before a good and well-thought reasonable plan backed "by real code"(TM;-) is almost appreciated. >> Personally I use apache/mod_wsgi a lot for development, and have a >> custom .wsgi script using the monitoring described on this page: >> >> http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode >> >> That way I can for instance add easy-install.pth to the file list to >> be monitored, so that whenever i install or update any plugins, the >> deamon process restarts itself and loads the new code. > > mod_wsgi rocks, but its an Apache-only solution, which is not trendy > at the moment. Why waste time for Apache/mod_wsgi config when there > are plenty of Python-based servers that work out of the box. Apache is > an overkill for occasional plugin development. So this is mod_fcgi, or what else? Sorry, I'm not remotely an expert in that field, so would value, if you'd not speak clearer here and just name it, thanks. Steffen Hoffmann (hasienda) [1] http://trac.edgewall.org/wiki/MacroBazaar [2] http://trac.edgewall.org/wiki/ProcessorBazaar [3] http://trac-hacks.org/wiki/QuerySystemPlugin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkyFZxQACgkQ31DJeiZFuHexyACfSX66DCAfuHRXbhrkM7ud4Er8 bp0An10h2gXJMqrpkCKWIq0P0pdSlLjt =jXp2 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
