[tg-trunk] Re: [TurboGears] Anybody Available To Talk?
I'm willing. Not sure if I'm helpful, but I'm willing ;) On Fri, Apr 13, 2012 at 10:56 AM, Michael Pedersen m.peder...@icelus.org wrote: Thanks to +Michael Bernstein and his posts about #LeanStartup, I'm finding myself questioning whether or not my business idea is a good one. I'm looking to start up a company that will fit between the offerings of Monster and LinkedIn. Anybody available over the next two weeks for a short interview? I'd be conducting them between 9pm and midnight eastern time. Let me know if you're willing. -- Michael J. Pedersen My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen Google Talk: m.peder...@icelus.org -- Twitter: pedersentg -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG namespace things
I think it's the only way for us to control our own destiny for the future, so I'm +1 on it.And I agree that what we ultimately want is for tg.i18n and tg.session and tg.config to be the way we tell everybody to use tg -- that way we expose a consistent API and make pylons/pyramid/paste/formencode/etc into implementation details. --Mark Ramm On Tuesday, June 21, 2011, Michael Pedersen m.peder...@icelus.org wrote: I'm not sure, honestly. We do expose a lot, but is adding more a good idea? Unless we lay claim to it and say tg.varname is how you do x. btw, for now, tg.varname is a direct line to this var over in Pylons, but that can change later. On the surface, the idea sounds good, I'm just not sure it's the way for us to go forward. Thoughts from anybody else? On Tue, Jun 21, 2011 at 1:17 PM, Alessandro Molina alessandro.mol...@gmail.com wrote: Most of the pylons things used by TurboGears are accessible from the tg.* namespace directly.I think that this is indeed good as it keep an high level of abstraction from pylons itself and gives use more freedom for future evolutions. I was thinking to take a look around in the documentation, look of each pylons.something function used inside the doc and migrate it to tg.something.Also if in the process I discover something that isn't available inside the tg namespace I woud expose it inside tg itself. What is others opinion about this? Any one against doing this? Alessandro -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen Twitter: pedersentg -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG elixir support and templates cauldron
I think that providing Elixir is a bonus, but it makes harder to keep things in shape (and to me it seems that the story reported by Jorge confirms this) so I would proposte to have it as a separate package. I definitely think Elixir support takes work that would be better spent on other things. But I don't think it's a bad thing so if somebody wants to do that work, great. If not, that's fine too. Declarative makes elixir mostly superfluous anyway -- and it's right in SA core. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG Project home on SF.net
There is no way to do virtual name hosting right now, sorry. If it's an important feature, I can think about prioritizing it. On Mon, Apr 4, 2011 at 10:34 PM, Michael Pedersen m.peder...@icelus.org wrote: Actually, I've got another question: Mark, how do we do virtual name hosting for sf.net? For instance, I want to point svn.turbogears.org to the svn repository for TG1, and git.turbogears.org to the project page for TG2. On Mon, Apr 4, 2011 at 10:23 PM, Michael Pedersen m.peder...@icelus.org wrote: Just a quick follow up for Mark: Is there a way to do this? I can always add a redirecting .htaccess in the web space. Is there a better way? On Thu, Mar 31, 2011 at 1:37 PM, Christoph Zwerschke c...@online.de wrote: Am 31.03.2011 15:02 schrieb Alessandro Molina: I have just noticed that turbogears.sf.net is currently set as the project home for TG2 project on sf.net. It might have sense to update that to http://turbogears.org/ to avoid problems for new users that found the project searching for a framework on sf.net Even worse, the project home link is broken if you are logged in since it does not work with https. But it's not obvious how and if this can be changed for a new style SF project. Mark? -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- All humans fail, in both great and small ways we fail continually. Machines fail too. Computers are machines that are managed by humans, the fallout from failure can be spectacular. Your responsibility is to deal with failure, to anticipate it and to eliminate it as far as is humanly and economically wise to achieve. Are your actions part of the problem or part of the solution? -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- All humans fail, in both great and small ways we fail continually. Machines fail too. Computers are machines that are managed by humans, the fallout from failure can be spectacular. Your responsibility is to deal with failure, to anticipate it and to eliminate it as far as is humanly and economically wise to achieve. Are your actions part of the problem or part of the solution? -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Status Update - Mar 28, 2011
My mistake, I mixed up eggbasket with basketweaver. You're right, it's static files, and that is the route I'm leaning. Mainly because I'm used to it. If there's better, let me know, I can change. it's hard to beat static files served up by nginx for performance scalability and reliability. --Mark Ramm -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Status Update - Mar 21, 2011
It is having some trouble crawling that repo, but once it's done it will have the author and commit message data. All the SVN repo's we've processed have worked, but the TG repo is special in some ways, so it's helped us find a couple of bugs. ;) On Sat, Mar 26, 2011 at 8:32 AM, Christoph Zwerschke c...@online.de wrote: I have now migrated the Subversion repository from the old TurboGears server (http://svn.turbogears.org) to SourceForge (https://sourceforge.net/p/turbogears1/code/). The transfer took several hours since the SVN repository is huge: It contains the hisotry of the complete website with all the required files, videos etc. (close to 1GB). Please let me know if everything is there. It seems Allura has indexing problems again: If you click on a commit or on the history, the author name and commit message is not displayed in many cases. Also, does Allura not display diffs? -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Status Update - Mar 21, 2011
We have not yet pushed the new async task system that used MongoDB to persist task data and assure it's completion, but that should go out next week. In the meantime if there's anything that doesn't sync into the search results, let me know and we can reindex the tg tracker. --Mark Ramm On Thu, Mar 24, 2011 at 6:25 AM, Christoph Zwerschke c...@online.de wrote: Thanks. I hope we can then finish the Trac migration this weekend. -- Christoph Am 24.03.2011 05:08 schrieb Mark Ramm: That should be fixed now. Rabbitmq failures at the time of the ticket entry meant they were in mongo but not solr. New updates to allura should mean this will never happen again. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Status Update - Mar 21, 2011
That should be fixed now. Rabbitmq failures at the time of the ticket entry meant they were in mongo but not solr. New updates to allura should mean this will never happen again. On Tuesday, March 22, 2011, Christoph Zwerschke c...@online.de wrote: Am 22.03.2011 02:37 schrieb Michael Pedersen: That's really it. We're in the same position we were for the last status report a week ago. Same for TG1. http://sourceforge.net/p/turbogears1/tickets/ still does not show up the tickets I've entered 2 weeks ago. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
I'll talk to folks on this end and make sure we get the migration API docs pushed out into a publicly accessible place. --Mark Ramm On Wed, Feb 16, 2011 at 10:48 PM, Michael Pedersen m.peder...@icelus.org wrote: On Wed, Feb 16, 2011 at 6:44 AM, Christophe de Vienne cdevie...@gmail.com wrote: IMHO it is worth fully migrating to SF, even if limited - having to maintain those tools should not be a burden for the dev team. As for the hosted trac, I would avoid it in the long term. We want to migrate to SF entirely, make no mistake. What we're saying is that, right now, we might not be able to do so. At the least, the code is now in git, and the git repositories are hosted on SF. I've even prepped up a possible bit of web work that, once everything else is ironed out, could work for the web presence under the pylonsproject pages. Even with all that, without issue tracking, we've got nothing. And without being able to migrate our current issues into the SF base, we can't complete the migration to SF. If we can't get the migration to occur (due to lack of docs), let's at least not hamper ourselves with outdated software. We can upgrade Trac, so let's make that happen. It might require me setting up a linode instance to get full/proper Trac support with git and multiple setups, but I'll deal with that when it comes down to it. On Wed, Feb 16, 2011 at 6:50 AM, Alessandro Molina alessandro.mol...@gmail.com wrote: Stable code related to the in development version or code of stable releases? As I think that it is usually better to have development code on master and stable releases on their own branches as it makes easier to release patches and fixes for that specific release. Well, what I'm reading makes me think that the common/accepted practice for git is to have the master branch be the nothing happens here branch. Basically, whenever a development cycle is closed, the tag gets applied, everything gets migrated to master, and the development branch picks up new topic branches from there. This seems to have an advantage that all code (security fixes, especially) will eventually find its way to the master HEAD, or it's not fully integrated, and there's no question about it. Having a branch for all 2.1 code would allow a security fix to be applied only to 2.1, and never applied to master, and that would be (almost guaranteed) wrong. I'm open to hearing why my understanding is wrong, though. I'm not a git master, and am willing to be shown a better path. Not a problem, it would be better just to have them on sf.net for later inclusion than having them on a forgotten bitbucket project :D Now that I can agree on wholeheartedly. As of right now, I think I'm going to say to fork a git repository on SF.net. From there, make a branch and add Chris's changes to it. Send a pull request, and I'll sync it back up so that it's available for everybody. Oh, and I did just check it out. That does all work. I've even added a pu branch for proposed updates. Put the new dispatch work in as a branch from pu, and we'll go from there. BTW, before you think I came up with pu from thin air, I swiped the name directly from Git itself. It's what they use to start a controversial change, so I figure it should be able to work for us, too. On Wed, Feb 16, 2011 at 8:01 AM, Christoph Zwerschke c...@online.de wrote: You mean Trac in general, or a hosted Trac on SF? I can imagine using a current Trac version on our own server, as one instance with two (or three) Trac environments for TG1 and TG2 (and TG3), each configured to use the corresponding repository. For TG2 (and TG3) we would need the Git plugin as Trac has built-in support only for SVN. I'll admit to being confused still: Which machine is Florent's? Where does the current www.turbogears.org actually point? Can we even possibly make the git plugin work on the current www.turbogears.org, or do we need to switch things around so that Trac will work? On Wed, Feb 16, 2011 at 10:48 AM, Kevin Horn kevin.h...@gmail.com wrote: This is a would be really great to have happen. I think there may be a bit much going on right now to get too wrapped up in it, but it should definitely be on the radar. CI in particular would be a great help. We're not going to have it for 2.1.1. Can't be done in a reasonable enough time frame. 2.2, though, is a whole different beast. I want to see these tests there. As far as integration/performance tests, what were you thinking? Behavior-driven tests, using something like Lettuce or PyCukes? Scripted installations? Something else? I'm thinking that we should be able to do the following: full unit testing with 100% coverage testing of the installation from scratch (ultimately, on a variety of platforms) performance testing (using pystones to benchmark the machine, and then using that to normalize the requests/second for a few pages out of a quickstarted application
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
There is a Trac import and export script example for sf.net here: http://sourceforge.net/p/allura/git/ci/e1c0a20357afc3af25f470cc3488ad3d5127c352/tree/migrate-3rdparty/ On Thu, Feb 17, 2011 at 11:50 AM, Michael Pedersen m.peder...@icelus.org wrote: I'll get myself logged into it tonight and check it out. I'm not going to promise anything. I will say that it looks promising, though. Then again, github looks promising, too. Part of me wonders if we might not be better off with github vs SF, too. Some of what they offer looks amazing in comparison. I'm still holding off on finalizing migration choices until this weekend. Hopefully Florent will speak up and/or we'll find the migration docs up on SF.net. Something will happen this weekend, though. I just don't know what. On Thu, Feb 17, 2011 at 11:30 AM, Christoph Zwerschke c...@online.de wrote: Am 17.02.2011 16:18 schrieb Michael Pedersen: So, what's the difference between using Trac tasks and flow.io http://flow.io? Especially if we throw in something like a gantt chart plugin? (I have seen that one, even used it, so I know it exists and does well). Especially since people can be on Trac, take tasks, etc. I would use flow.io for coordinating the general project management related tasks and workflow and Trac for keeping track of concrete, detailed development tasks directly related to the code. The advantage of flow.io is that you see who is working on what at the moment and get a nice overview of what has been done recently and what needs to be done next. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Status Update
I think the sf.net tracker service is better than the hosted app offering primarily because you can't install plugins into that trac, and we're actively developing features for the main tracker. I work with a large project using it every day, and find it to be pretty flexible and easy to use. --Mark On Tue, Feb 1, 2011 at 12:29 PM, Christoph Zwerschke c...@online.de wrote: Mark, what do you recommend for bug tracking at SF? The SF tracker or Trac as hosted app or even something different? Last time I had a look at Trac on SF, it came only with some basic plugins and did not allow much customization. Has that been improved? -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Status Update
Let me know your sf.net username and I'll get you admin rights. --Mark Ramm On Tue, Feb 1, 2011 at 5:51 AM, Christoph Zwerschke c...@online.de wrote: Am 01.02.2011 06:37, schrieb Michael Pedersen: Seriously, when I run it, I get presented with a slew of merges to do, and the first several of them resulted in merges to tg/controllers.py. There should be no merges. Maybe you have an old Mercurial version, I have seen such strange things with older versions, too. Try upgrading or if you give me admin rights on SF, I can upload the repos. What do you think about a 2.1.1 release? It would be a solution to the few annoying bugs of TG2.1 and would permit to test the new tickets and repositories environment. I think that we're too early in this restructure to ponder what the next release can or should be, or when it should be. Once we complete the migration to sf.net, we can focus on figuring out what the next release should be. Yes, but Alessandro is right, after the migration the first thing should be to get a 2.1.1 bugfix release out. 2.1 was released in a hurry and there are some things that already have been fixed. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TurboGears 1 branch
Thanks for making this happen. I don't have any 1.x apps rolling around any more, but I know that there are lots and lots out there, and serving that group well is critical. The other new and positive change in tg3 planning is that we are trying to put together a legacy handler that works with tg1 as well as tg2 apps, so there will be another migration opportunity that doesn't require rewriting your whole app. Ideally the Pylons Project will also support SQLObject directly in Pyramid, since it is not opinionated in the way that TG and then TG2 were about data persistance libraries. --Mark Ramm On Sun, Nov 7, 2010 at 8:38 AM, Christoph Zwerschke c...@online.de wrote: Notwithstanding the exciting news from the Pylons + repoze.bfg camp and the possible implications for TG3 (whatever it will be called), I'm still caring about the TG1 branch since I'm running and maintaining some important webapps based on TG1. I have worked on the TG 1.5 branch this week and ported one of my apps from TG 1.1 to 1.5. The major change in TG 1.5 is that it is based on CherryPy 3 instead of CherryPy 2, and that it fully supports Genshi, not only for page templates, but also for TG widget templates (but Kid is still possible for both). TG 1.5 works quite well for me and I plan to push out a beta release soon. However, I want to use the opportunity to also clean up the TG 1 docs. My idea is to consolidate and simplify the existing docs, merge everthing in RoughDocs to the official docs, and maybe finally move everthing to Sphinx. I you have objections or better ideas what to do about the TG 1 docs, let me know. Also, we should continue to work on the TG 2 docs. Unfortunately, the last doc sprint was cancelled because the Pyramid news caused too much turmoil and not enough people showed up. If anybody wants to organize another sprint, I will participate there as well. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.comturbogears-trunk%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TurboGears 2.1rc1 is released!
Thanks everybody who contributed, and special thanks to Chris Perkens and Michael Pedersen who spent their valuable saturday night pushing this release up to the servers, testing stuff, and otherwise being awesome. --Mark Ramm On Sun, Oct 17, 2010 at 2:19 AM, percious ch...@percious.com wrote: It’s been a long summer, and the TurboGears crew has been busy testing the new release candidate on our own production sites. We think the release is ready for introduction into the wild. One of the reasons this release has been delayed is due to the release of Pylons 1.0, which 2.1rc1 now supports. In fact, only one routing change has taken place which removes the possibility for infinite recursion, and this should not affect the majority of users. Of note is the addition of support for kajiki, which is a super-fast xml-based template language. This release does not come without some serious toil from the part of our docs team, headed up by Michael Pedersen. I would also like to thank Mark Ramm and Rick Copeland for their work to provide an alternative xml templating language. Thanks to all involved in the last sprint which helped this release move along. Docs can be found at: http://www.turbogears.org/2.1/docs/ cheers. -chris -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] Development sprint in October?
Anybody up for taking the lead on putting together a distributed development sprint this month? In addition to a sprint, I'd like to propose an IRC meeting to talk about how to get done what we want to do: * Sf.net transition plan * Doc sprint * 2.1 release planning * etc I'm thinking about doing a quick get together on IRC, perhaps Wednesday the 13th in the morning for us folks (like 10 am EST, 8 mountain, 7 pacific), just to get organized about where we're headed over the next few months. There are some big questions about where we go post 2.1 that I want to make sure we're starting to think about, so that would be another section of the meeting. I'm not against some other time than the one proposed above, but if you want a different time please 1) make a proposal, and 2) volunteer to organize getting the word out for that time ;) --Mark Ramm -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] interesting new template engine
So, at work we're going to have a major TG project go live on the 13th. Ultimately it's going to be open source, but in the meantime there are some components that we've created along the way which can be released ahead of time. One that's very experimental and which we're not actually using yet is: http://www.pythonisito.com/fastpt/migrating_from_genshi.html Which is a new fast template renderer with a genshi-compatable template syntax. http://bitbucket.org/rick446/fastpt/src First, why another template engine? There was quite a bit of talk about Genshi becoming unsupported a few weeks ago, and while that's provoked a renewed energy in the project, it also highlighted the fact that nobody's yet been able to satisfactorily make genshi style templates fast. In particular I think it's possible that the combination of * a stream oriented approach * a match template approach to inheritance can't be made fast enough for complex high traffic, high performance sites. Anyway after a couple of conversations, and a bit of genshi performance trouble at work, Rick Copeland hacked this together, and it supports jinja style template inheritance, and no match tags, but is otherwise an attempt to be a faithful genshi clone. There's not much code, and what's there is pretty clean and the genshi benchmarks show it being **slightly faster than mako** and **way faster than genshi.** FastPT is experimental software, and will remain so for a while, but I think it's a very very promising library -- in our internal tests we had something like a 40% overall page/second improvement just by switching from genshi to FastPT. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] EasyWidgets
We've been using a new widget library in a project at work, and while it's been open source for a while, we've not been talking abou it much. It was in many ways an attempt to return from the framework independence, and complexity of toscawidgets to be a bit more like the original turbogears widget library. http://bitbucket.org/rick446/easywidgets/ Right now it competes pretty directly with toscawidgets 2, and ToscaWidgets has some advantages. I'm hopeful that either 1) the EasyWidgets and TW2 devs start working together or 2) the competition between the two widget frameworks sparks continued innovation Right now I see the advantages of EasyWidgets as being: * server side stuff handled by standard TG controllers * auto-concatenate support for resources * support for cache-busting config value * no injection middleware * support for CDN via a read-through static resource cache At the same time TW2 has: * more docs * slightly more maturity --though it's still very publicly only available in alpha * more framework independence -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] State of Turbogears
Ok, so it's been more than a week, and I'm still not quite ready for a state of the union type message. I've got a big release of a new TG based product that will serve a very large (2+million registered users) population, and that's been taking up a lot of my time. But, more than that there's a lot going on in the last couple of weeks, and I expect a lot more in the next month or so. There are a couple of show-stoppers for 2.1, but it's very close to ready for release, so I expect I'll be focusing my attention there for the next couple of weeks. There's been some very interesting progress coming from a lot of fronts, Chris P and others have done some good work on a TG based CMS some great new extensions from Michael Pederson, and we have some interesting experimental libraries that I want to get out into the wild for wider discussion. I'll put out a better state of the union type message soon, but I feel like there are several larger public discussions that we need to have before we get there, so I'm going to focus on getting those conversations happening right now. --Mark Ramm On Fri, Jun 18, 2010 at 11:20 AM, Mark Ramm mark.mchristen...@gmail.com wrote: I'll write something up and post it here next week. RIght now I'm in the midst of getting a largish TG2 app out the door, and am pretty swamped. --Mark Ramm On Wed, Jun 16, 2010 at 11:46 AM, Derick Eisenhardt derick.eisenha...@gmail.com wrote: Could Mark, Percious, or someone deeply in the know give us some sort of update on what's been going on and what future plans are? This list has been frighteningly quiet for the last few months. As a developer who has put quite a bit of time into a TG2 based app, I'd really like to get a better sense for where the project is heading. Will the 2.0.x branch ever get another update? What's the status on 2.1? Plans for 2.2? Have we been losing developers or gaining them since the release of 2.0? Post it here, post it on your blog, just please give your users some more communication on the state of things. thanks, - Derick -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] State of Turbogears
I'll write something up and post it here next week. RIght now I'm in the midst of getting a largish TG2 app out the door, and am pretty swamped. --Mark Ramm On Wed, Jun 16, 2010 at 11:46 AM, Derick Eisenhardt derick.eisenha...@gmail.com wrote: Could Mark, Percious, or someone deeply in the know give us some sort of update on what's been going on and what future plans are? This list has been frighteningly quiet for the last few months. As a developer who has put quite a bit of time into a TG2 based app, I'd really like to get a better sense for where the project is heading. Will the 2.0.x branch ever get another update? What's the status on 2.1? Plans for 2.2? Have we been losing developers or gaining them since the release of 2.0? Post it here, post it on your blog, just please give your users some more communication on the state of things. thanks, - Derick -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] I've taken a look at 2.1b1
3. pagination does not work, as url_for fails (there's a ticket for this issue) I believe Chris Perkins fixed pagination at the sprints this week, so you might want to make sure pagination is fixed for you in trunk. There will be a b2 release sometime soon, so you could wait for that too. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Admin list view fails with more than 8 records
Thanks! I can confirm and created ticket #2455 for this. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] a couple of patches
- make override_template work for all content types I use this to a have single controller serving javascripts generated at runtime from templates, so that calling /parsedjs/scriptname.js will parse scriptname.mak and return the result with a content_type of text/javascript. (At the moment override_template only works for the text/html engine) Sounds like a very reasonable an simple patch. Definitely post this to trac. - allow custom REST-like methods in RestController I added this to have a consistent API, exposing custom methods the same way as REST verbs. For example you can define get_archive() and post_archive() in your movies controller and use them like this: GET /movies/1/archive POST /movies/1?_method=ARCHIVE This is possibly more controversial since one of the REST principles is to limit the number of verbs in the system. But, I still think it's worth discussing further here and posting to trac. --Mark Ramm -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: failing tests in tg2.0 - who's responsible?
I've added looking at this merge to my todo list for this week. It's a pretty crazy week at work, but to get passing tests, I'm willing to go out of my way as much as possible ;) --Mark Ramm On Mon, Jan 25, 2010 at 12:25 AM, Anthony Theocharis anthony.theocha...@gmail.com wrote: The tests that fail in tg 2.0.3 should all be fixed in my branch, which is waiting to be merged (nobody has offered yet) at http://bitbucket.org/anthony.theocharis/tg-2_0 . I posted a message to the turbogears group, but I'll copy it to the tg-trunk list here. I guess it's the more appropriate forum. -- Anthony On 24-Jan-10, at 6:57 PM, percious wrote: For those of you who may have read this previously. The recommended way to patch TG (and have it easily accepted) is as follows: set up an account at http://bitbucket.org fork a copy of http://bitbucket.org/turbogears/tg-dev clone your forked copy. Make your changes. Changes that include tests that break before the fix, but work after the fix are more easily integrated. Also, be sure that your new code does not break the existing tests. push your changes up to your repo. send a pull request, open a ticket in trac with a description of the problem and solution. cheers. -chris On Dec 1 2009, 7:00 am, Diez B. Roggisch de...@web.de wrote: Bump. No takers on this? Additionally, I'm having difficulties with mercurial to create a patch for the 2.1-branch of my working fix for the before_call-fix - at least in the mercurial way. Can anybody lend me a hand on this? that would be great. Diez I'm attending to some bugs in 2.0.3 we hit. When running the test-suite, there are 4 tests failing: tg.tests.test_tg_controller_dispatch:TestTGController.test_new_default tg.test_stack.rendering.test_custom_format:test_html_custom_format tg.test_stack.rendering.test_custom_format:test_xml_custom_format tg.test_stack.rendering.test_custom_format:test_json_custom_format Can somebody confirm this? The custom-format-stuff is especially dangerous, because without it running the much bigger error lurking behind it can't be fixed. It has the same race-condition issues that I already fixed for override_template. Diez -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/turbogears-trunk?hl=en. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: [TurboGears] Patches for TG 2.0.4?
As I said in the other thread, I'll take a look ASAP. That is if Deets doesn't beat me to it ;) If nothing else, I'll merge these in this weekend, but I'm hoping for earlier than that. --Mark On Mon, Jan 25, 2010 at 4:20 AM, Anthony Theocharis anthony.theocha...@gmail.com wrote: I should add that the branch follows up on the following tickets with more complete solutions and tests: http://trac.turbogears.org/ticket/2303 http://trac.turbogears.org/ticket/2313 I haven't made a ticket in Trac specifically for this patch-set because there are a few different issues fixed (in addition to those two). They're all well described in the commit messages in the branch. -- Anthony On 24-Jan-10, at 9:28 PM, Anthony Theocharis wrote: I posted this to the turboge...@googlegroups.com list a few days ago, having forgotten that we had a specific group for development like this. Details in the paragraphs below. -- Anthony On 21-Jan-10, at 2:14 PM, Anthony Theocharis wrote: On 21-Jan-10, at 2:31 AM, Diez B. Roggisch wrote: Hi, I think this is mostly directed at Mark Ramm, but if anyone else has authority to approve the changes, I'd love to hear from you. I've got a bunch of patches (mostly bug fixes, but also patches to actually implement routing, all including tests) to TG2 that I'm really hoping we can quickly get merged into the TG2.0 official branch. http://bitbucket.org/anthony.theocharis/tg-2_0/ This is important for me not just because I want to see a functional, bug-free TG2.0, but because my company recently launched our first big TG2.0 driven open source application (Stuart, our director, posted about http://getmediacore.com/ MediaCore the other day), and it really needs these fixes to be easily accessible, so other users don't have to manually patch TG in order to use the app. If you provide them as bundle, I'm happy to apply them if they are test-covered, and of course don't brake existing tests. I can't comment on the when of a TG2.0.4 release though. We ship our own TG2-egg, and I think you should consider setting up your own package index anyway to guarantee stable versions. Diez Thanks for the quick reply! Tests are all there, and some of the patches actually fix other tests that were broken in the trunk. What kind of bundle do you need? I can provide separate patches in a .tgz file, but you should be able to merge them in from the forked bitbucket mercurial repository I linked to in the above quote. Thanks again, Anthony -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: Hello,
On Sun, Jan 24, 2010 at 10:04 PM, percious ch...@percious.com wrote: Hmm. Sorry to enter this party late. But I think sending a new helper off on a wild goose chase the size of SO support is a bad idea... While I think it would be nice to have SO support, i feel it is lower down in priority in terms of the needs of our project. Well, I was sending Daniel off on the SO support trail, more than Phinny, but yea the easiest place to get started with 2.x support is working on the docs. --Mark Ramm -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] 2.1b1 is released!
Thanks for all the hard work Chris! It's great to see all the features in this new release, and to see how you've raised the bar with 2.1. Great work. I also think special thanks should go to mpedersen, who has done great work improving the state of the docs for 2.1. --Mark Ramm On Mon, Jan 25, 2010 at 11:15 PM, percious ch...@percious.com wrote: The TG2.1 team presents our first beta. Thanks to all of you who helped ferret out bugs in the alpha stage. Here is a list of items fixed in this release. * Deprecated default in favor of _default * Fixed handling of Unicode parameters * Added disable_request_extensions flag to configuration to allow users to ignore the request extension dispatch bits of object dispatch. * Increased length of Permission.permission_name to 63 chars. * Fixed GET requests on nested RestControllers. * Fixed case-sensitive incorrectness in quickstart when using mako template option. * Fixed numerous URL routing bugs, consilidating the RC and TGC controller base. * Fixed eroneous tg.url call inside the quickstart template. * Added use_dotted_templatenames support for Genshi. * Added ignore_parameters setting in the config * Added ability to have sa_auth.cookie_secret in .ini file * Added cookie_secret to quickstart template * Added tgext template * Added backwards optional support for TurboJson So, this is a considerable number of fixes, and I don' think that we are far-off from our first release candidate. My plan is to produce 1 more beta right before pycon, then a release candidate in march, with 2.1 final in early April. If you are considering upgrading to 2.1 from 2.0, this might be a good time to test the waters and get back to us. Most of the changes were in the dispatcher this time around, so I am guessing we got most of those bugs ironed out. I can tell you this, the dispatcher was much easier to fix than in 2.0. Here's some stats on this release: tg: 18 files changed, 518 insertions(+), 256 deletions(-) tg.devtools: 17 files changed, 416 insertions(+), 15 deletions(-) Thanks again to everyone who contributed bugfixes, especially those that came with tests, that made my job a lot easier. We closed about 25 tickets this round. Great job guys. cheers. -chris -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Hello,
I'll take a bit and try to work up what you need. For super basic support you just need to implement the equivelent of zope.sqlalchemy to do the automatic transaction stuff using the transaction manager (i think that part's pretty straightforward) , and a new method for the configuration class that sets up SQLObject from config values in the ini file. The next step would be to setup the identity provider classes in SQLObject rather than SQLAlchemy. There is some documention on how to to this for repoze.who/what but I'd start with the two things above. --Mark Ramm On Tue, Jan 19, 2010 at 11:36 AM, Daniel Fetchinson fetchin...@googlemail.com wrote: What I personally would like to see in tg2 is support for sqlobject. Please someone who uses SQLObject, help us with this. I don't think this is a major project at all, but while it gets requested here on the mailing list every once in a while, nobody seems ready to help make it happen. I'd give it a shot but are there any kind of documentation, tips, ideas about integrating ORM's with tg2? I basically have very little knowledge of tg2 and am more familiar with tg1 so don't really know what it takes to integrate sqlobject. What hooks are available for this? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Hello,
What I personally would like to see in tg2 is support for sqlobject. Please someone who uses SQLObject, help us with this. I don't think this is a major project at all, but while it gets requested here on the mailing list every once in a while, nobody seems ready to help make it happen. --Mark Ramm -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] sa_auth.cookie_secret and development.ini
Also, when you set sa_auth.cookie_secret in the ini file, it shows up as config['sa_auth.cookie_secret'] and needs to be pushed into config['sa_auth'] somehow. Anybody know the recommended way of doing this? Surely there must be some kind of helper somewhere... There should be some crazy hubajoo to turn dotted key names into nested dictionary members inside the config object itself. If that's not working, and I'm betting it's not, it's because the logic of that method is: Our custom attribute getter. Tries to get the attribute off the wrapped object first, if that does not work, tries dictionary lookup, and finally tries to grab all keys that start with the attribute and return sub-dictionaries that can be looked up. Since there is a sa_auth already defined in the app_cfg, the crazy magic that makes attribute lookups work for dotted names, isn't going to kick in. This whole config system is a bit convoluted, and perhaps could use a revamp in the next (post 2.1) version of TG. But for now, there are a couple of obvious options: 1) Move the stuff that's defined in app_cfg out into the ini file, and the above logic will work 2) Monkeypatch things like you've done above. I think Michael is working on a patch to move the default to the right place (the .cfg file) right now. --Mark Ramm I wrote this workaround for 2.0.3 (I was too fed up at this point to patch it properly): class MyAppConfig(AppConfig): def setup_sa_auth_backend(self): super(MyAppConfig, self).setup_sa_auth_backend() if 'sa_auth.cookie_secret' in config: config['sa_auth']['cookie_secret'] = config['sa_auth.cookie_secret'] self.sa_auth = config['sa_auth'] I think the quickstart project should *default* to storing the cookie_secret in the ini file. If you consider the distribution of an open source app, clearly the secret should be unique to each deployment and changing it shouldn't require modification of the app itself. This way it's value can be generated automatically when you run 'paster make-config', as is already the case with the beaker secret. Are there any disadvantages I'm not seeing? Cheers, Nathan On 2009 Dec 15, at 4:57 AM, Sanjiv Singh wrote: Hi Mike, This one is due to http://trac.turbogears.org/ticket/2414 The code was backported from 2.0.3 to avoid two different quickstarted apps trusting each other's cookies unless it is specifically changed. But I agree that we need a better solution for it and I believe Mark had something in mind. Mark? Sanjiv On Tue, Dec 15, 2009 at 10:53 AM, Michael Pedersen mjpe...@gmail.com wrote: I'm now officially confused. I had a quick start environment working using tg2.1a1 (at least, and I think it was working with 2.1a2). I could get paster serve to show pages. All was happy in my world. I've updated to 2.1a3, and I'm now getting told to set up sa_auth.cookie_secret in my app_cfg or in my development.ini file. I attempt to add a different cookie_secret to my development.ini file in sections DEFAULT, server:main, and app:main. None of those locations work. How do I put the cookie secret into my .ini file (thereby making it easily changed on a per installation basis without altering the app_cfg code)? -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/ pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com . To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears- tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en . -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com
Re: [tg-trunk] TG2 decoration issue, thoughts anyone?
Done. Thanks again for your help! On Fri, Nov 20, 2009 at 10:57 AM, Mark Ramm mark.mchristen...@gmail.com wrote: I am admin at tg 21 it seems - so maybe if you give me admin-rights to 2.0, I can tag it? I would only tag 2.0.3, trying to go back in time check which version was 2.0.1 I don't know how to do. Sure, I can do that! Thanks. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
Re: [tg-trunk] TG2 decoration issue, thoughts anyone?
I am admin at tg 21 it seems - so maybe if you give me admin-rights to 2.0, I can tag it? I would only tag 2.0.3, trying to go back in time check which version was 2.0.1 I don't know how to do. Sure, I can do that! Thanks. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
Re: [tg-trunk] TG 2.0.3 tag
Yea, it's an omission. 2.0.3 was a massive overnight effort to fix a security hole, and I missed a step in the release process. Sorry about that everybody. I haven't had any concerted time to go back and figure out which version should be tagged for the release, but I don't think I've seen a 2.0.x commit since then. I should have time to figure this out this weekend if nobody else can do so. --Mark On Thu, Nov 19, 2009 at 10:58 AM, Diez B. Roggisch de...@web.de wrote: Hi, I might need a fork of TG 2.0. I tried and searched http://bitbucket.org/turbogears/tg-2_0/ but didn't find a release-tag for 2.0.3. Is that just an ommission, or am I'm missing something? Diez -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
Re: [tg-trunk] TG2 decoration issue, thoughts anyone?
I haven't noticed this yet, and have been heads down because of family issues and work, but I'll try to take a look this weekend if I can. But on the face of it it seems like something we should definitely consider for 2.0.4. And I do think we should do a 2.0.4 release, it'll either happen in the next two weeks, or sometime towards new years as I'll be offline for a bit in the middle of December. --Mark Ramm On Tue, Nov 17, 2009 at 10:49 AM, Diez B. Roggisch de...@web.de wrote: Hi, we just stumbled over a peculiar behavior due to the use of Decoration objects on actions. The problem is that in case of validation-errors, execution is delegated to an error_handler (which might be the decorated action itself of course). The responsible method is _handle_validation_errors Now the problem is that this call is a simple call that doesn't respect the before_call and before_render/after_render hooks: if error_handler is None: error_handler = controller output = error_handler(*remainder, **dict(params)) elif hasattr(error_handler, 'im_self') and error_handler.im_self != controller: output = error_handler(*remainder, **dict(params)) else: output = error_handler(controller.im_self, *remainder, **dict(params)) My suggestion would be that the hook-handling-code that gets used in the normal case is refactored into a method on DecoratedController itself, and then used from both normal dispatch, and inside _handle_validation_errors. If this isn't done that way, we violate expectations of developers. So the first question: what do others think, do we need this? If the answer is yes, read on ;) I'm personally not yet willing to go to 2.1 alpha. I need a stable 2.0 version. Howere, the code in question is largely the same in both branches, so I'm happy to develop two patches (or maybe one works for both, dunno). So the second question is: how about this regarding 2.0's maintenance state. Is there a bug-fix release 2.0.4 coming, and if yes, would this be considered a bug that should be backported? Diez --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~--- -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
Re: [tg-trunk] Re: [TurboGears] observations about TG 2.1
from simplegeneric import generic @generic def jsonify(obj): '''existing default method rules go here''' class GenericJSON(JSONEncoder): def default(self, obj): return jsonify(obj) Maybe a tweak or two needs to be made, but that is largely all that needs to be done to go from 95% to 100%. If you wrapped the import in a try/except and only added the generic function stuff if simplegeneric is present on the system I think everybody would be 100% happy, even jorge ;) --Mark Ramm -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
[tg-trunk] Re: [TurboGears] Critical security update for tg2 users!
The index is required right now, but that will change in the future. I did use it in the example in the e-mail, so it's not like it was undocumented, but yea, it will be nice when it's not required anymore. If we required a higher version of repoze.who that would update automatically, but rather than force updates on people 2.0.2 provided the minumum change that people needed to get bugs fixed and the security holes patched. We will likely make a metapackage in the future that has all the dependencies and pushes them to the latest version so that we can do a -U on that directly. On Thu, Aug 13, 2009 at 11:40 AM, Derick Eisenhardtderick.eisenha...@gmail.com wrote: This upgrade system doesn't seem to work very well, or at least not as expected. First off, it needs to be: easy_install -Ui http://turbogears.org/2.0/downloads/current/index/ TurboGears2 to actually pull 2.0.3, without index in the URL it doesn't seem to really do anything. Secondly it only updates that one package, but none of its dependencies...after preforming both versions, my Repoze installed is still at 1.0.10, when it should be now at 1.0.15. Personally, I'm just gonna do a new virtual environment with a fresh install...but would be nice to be able to upgrade All :/ On Aug 12, 7:09 am, Mark Ramm mark.mchristen...@gmail.com wrote: I messed up the 2.0.2 egg in an svn merge mistake, so we've now relesed 2.0.3 with a fix. Install instructions are the same. easy_install -Uihttp://turbogears.org/2.0/downloads/current/TurboGears2 -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [TurboGears] Critical security update for tg2 users!
I messed up the 2.0.2 egg in an svn merge mistake, so we've now relesed 2.0.3 with a fix. Install instructions are the same. easy_install -Ui http://turbogears.org/2.0/downloads/current/ TurboGears2 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Critical security update for tg2 users!
We recently discovered that TurboGears2 ships with quickstart configuration that leaves users of it's default user authorization/authentication scheme vulnerable to a serious security issue. If you are running a TG2 application in production you are strongly encouraged to set the cookie salt for the authorization cookie in repoze.who to something other than it's default value. This is simple enough to do, just set base_config.sa_auth.cookie_secret to any secret value you'd like. For example: base_config.sa_auth.cookie_secret = mynewsecret You can also set it in development.ini using a key like: sa_auth.cookie_secret = mysupersecret Failure to do this could leave you vulnerable to someone who knows the default cookie secret being able to craft a cookie that allows a user into your site without authenticating through the normal mechanism. TurboGears 2.0.2 will enforce setting the cookie secret and will refuse to run if you have not set that value in your configuration. We've just released 2.0.2, which also fixes another security issue which could cause controller methods decorated with something other than @expose to still be exposed through the URL dispatch mechanism. You can update to 2.0.2 with easy_install -Ui http://turbogears.org/2.0/downloads/current/ turbogears2 -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Future of TG
There's a quote at the end of the second Terminator movie that feels very appropriate here: The future's not set. There's no fate but what we make for ourselves. I'm not planning on proscribing the future of the project, and I'm definitely not going to tell people what they should do. But I do want to help provide some vision for where I personally hope that we go, and to let you know about a few people that have volunteered to step up and help us to forge ahead into the whatever future we decide to make for ourselves as a community. I've been off working on work projects and dealing with various other real life problems, which have distracted me personally from putting the attention into the post 2.0 TG work that I'd hoped to do. There is good news for TG in what I've been up to for work, and as a result TurboGears 2 is now powering all of the project and download pages at SourceForge. We've got lots more usability improvements to come for people who download and use SourceForge software. I thought this was the highest traffic TG2 deployment, but I heard about a couple of things here at EuroPython this week that make me think there may be some other equally large sites out there. So, I think we've got a good marketing case to back up our claims that TurboGears can scale up to handle lots of traffic. At the same time, we're moving forward on lots of other fronts: Florrent Aide has volunteered to become the TG2 release manager, and to help us to improve and systematize our release process. He's already gotten started in making some improvements to the TG2 install process, and his diligence, consistency, and problem solving ability have been clearly demonstrated in his TG1 work, and I'm very excited that he's stepping up to help with this stuff. Jonathan Schemul has volunteered to take a leadership role in turning beta.turbogears.org into the best marketing website that we can find. And he will also be helping us to get a bit better organized around marketing material generally. I think these are two critical points for us to work on, and I'm very happy to have two such devoted and talented individuals step up and help move the project forward. There are two other areas that I think need focused leadership attention: * Documentation * Quality Assurance There's been quite a bit of good activity on the documentation front, and I'm particularly interested in merging some of that work back in to the docs trunk soon. One piece of the documentation picture that's not been working as it should is the 2.1 changelog. If someone would volunteer to go through the commit history on bitbucket and make sure to pester 2.1 developers who made changes to take a few min out of their busy schedules, and document them that would be great. We also need more test coverage, we've been moving in the right direction, and 2.1 has a lot more coverage than any previous version. Testing a framework built on integration can be complex, and our test infrastructure needs to be first class code. Which means it needs the same attention to re-factoring, cleanliness, and documentation that we apply to our main code. This is critical because we need to help people to get involved in the core, and this can only happen if they can also write tests ;) I'll talk to everybody and come up with a proposed timeline for the next 2.0.x release, and for 2.1, but I expect that we'll have a couple of releases coming up soon. Please feel free to chime in and lend a helping hand in whatever way you can. We need the community to steup up and do everything from editing docs for spelling/grammar or hanging out on IRC and answering questions, to organizing a simple TG2 based system where we can track these kinds of small tasks, which I think we should call quests. Thanks to all the people who've made what we've done so far possible. And thanks to those who are stepping up to help lead us, I'm already looking forward to what we can accomplish in the next few months ;) -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: The future of TurboGears
I have to jump in here on a quick note. This thread really distresses me. The amount of effort that has gone into say what should be done instead of actually doing it is ludicrous. snip Sorry Chris, but I have to pipe up here, IMHO that is bolagna. I love what you're doing and appreciate it to death, *but*... A project should *always* want user feedback, whether it's positive or negative. Yes, negative feedback is valuable, particularly when it's constructive. But it's most valuable when it comes with an offer to help ;) If people want us to do more, that's great to know, but not something that we can promise (apart from some special grant of super-powers) since we're at the limits of our resources. If on the other hand people want to help out, there are a million ways, and we perhaps we're not doing a good job of getting people who want to contribute involved. That's a significant potential problem, but as far as I can tell it's a problem that's more potential than real. If anybody wants to help and doesn't know how, please e-mail me on or off list and I'll help you get started. And we do appreciate and value feedback of all kinds, but it can be hard to feel like you give a good part of your life for something and people keep asking for *more.* That said, I can take it, so if you want to level any particularly harsh criticisms, or provide a long list of demands send them to me via private e-mail. But seriously, it impacts the motivation of all the TG developers when they read a thread like this, and it really would help a lot if people spent more effort building up the community than demanding yet more work from the existing developer pool. --Mark Ramm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Security Issue with 2.0.0 (confirmed, please read)
This has been fixed and 2.0.1 is now up on the site. I will be doing an official announcement very soon. On Fri, Jun 19, 2009 at 8:32 PM, Jorge Vargasjorge.var...@gmail.com wrote: Hello Guys, Today on IRC diegows reported a bug with CrudRestController (from tgext.crud) which we later track to a bug inside TG that affect CrudRestController, RestController and all their subclases. Please note: - AdminController is not affected - TG2.1 is not affected. It basically boils down to RC not having a call to check for the security of allow_only, due to Which was introduced during the final set of Beta released but who cares now :) no one should be running anything older than 2.0 anyway. That said a fix has been code and it's on r6573 of http://svn.turbogears.org/branches/2.0 (remember nothing else should go to trunk as we are moving to hg) I already talked to Mark and we'll have a 2.0.1 release today or at most tomorrow. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TurboGears 2.0.1 released
This is a pure bugfix release. We fixed a major issue with allow_only security restrictions not working on crud controllers (and subclasses). If you use the CrudRestController or the CrudController you will want to upgrade immediately. Other fixes worth mentioning: - content_type support improved (now it's not ugly) - Jinja2 support is fixed - ToscaWidgets? http://trac.turbogears.org/wiki/ToscaWidgets now can be removed when use_toscawidgets is set to false - i18n logging now set to a sane default - and other minor fixed as explained in wiki/changelog 2.0.2 is expected to follow this release fairly quickly with a fix for custom routes and the __before__ method of DecoratedController not working because it has no decoration attribute. 2.0.2 will be the last release coming out of svn, all future releases will happen out of a soon to be created 2.0 branch at hg.turbogears.org. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: The future of TurboGears
We can't do it alone. We need help! But I am takeing your advice to heart, it's just that my time has become very limited, and I can't do it alone ;) --Mark Ramm On Wed, Jun 17, 2009 at 4:10 PM, Derick Eisenhardt derick.eisenha...@gmail.com wrote: So, TG2 finally has a stable release. However, it's release has sadly come out to little fan fare as far as most of the web is concerned. I'm worried by the current state of advertising/marketing and documentation, that what there is available currently has very little appeal to the majority of web developers out there. For TG2 to make any real traction it's going to have to appear to be the best of breed web development environments. As far as I can tell the only folks currently interested are those of us who have previously been using TG1, are hard core python fans, or are already sold on the idea of distributed/modular development (WSGI). That unfortunately leaves Turbogears with a somewhat niche audience. Django grew it's user base by advertising to people that it was the best, easiest to learn and use web development platform and better than Ruby on Rails. Their community seems to still be growing at rapid rates, while I've seen hardly any difference in new users around here since TG2 went final. At the end of the day, the average web developer doesn't care what platform they're using, or how it works...they just want the quickest and easiest method to get what their site running and doing what they want. Currently, TG2 still has a good bit of a learning curve. And I'm sorry to burst anyone's bubbles, but we DO NOT in any way shape or form have the best documented web development platform. And until it's retardedly easy for someone who has never programmed in Python, barely ever used the MVC model before, and knows nothing of command lines to jump in and make their first TG site in less than an hour, it's going to remain a niche audience. Beyond that our site is a bit of a joke currently. We're not even self hosting as far as I can tell. Now I know there's http://beta.turbogears.org out there, and I know folks are working on the Pages CMS. But we really should have had all that up before 2.0 went final. It's truely amazing how much a person will judge you're product simply on the the looks of your website alone, especially when the product is a web development platform. Furthermore, ToscaWidgets is dead in the water as far as I can tell and it's widget selection is sparse at best. It is absolutely imperative that TG have a full-featured widget toolkit built-in by default and it be just as well documented as any other aspect of the platform. TG1 had fairly good integration with MochiKit, but TG2's current stance appears to be you can either use this basic Tosca stuff someone threw together and then let stagnate for a year, or go out and find a real widget library (jQuery, Dojo, etc), but you'll have to figure out how to use it by yourself. And that is the exact opposite of the position we should be portraying to new users...if people want that situation, why not just use plain ol' Pylons? I hope I have not offended anyone here today, I'm just trying to tell it like it is. I implore you to not spend so much time on adding new features to 2.1 and focus on getting these core problems taken care of first and foremost. Please please please make 2.1 all about polish. I'd really love to talk to fellow developers and when I say I use Turbogears, they don't respond with a huh? what's that? -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Semantics of the tg.i18n.setup_i18n() function
Thanks. I just had to do 2.0.1 very quickly today, but I think we should get this integrated in as soon as we can and do a 2.0.2 release this week too. --Mark Ramm On Sat, Jun 13, 2009 at 12:59 PM, Timur Izhbulatov timoc...@gmail.comwrote: 2009/6/13 Jorge Vargas jorge.var...@gmail.com: On Fri, Jun 12, 2009 at 5:58 AM, Timur Izhbulatovtimoc...@gmail.com wrote: Hi all, I've been porting my app to 2.0 and noticed that setup_i18n() [1] doesn't set FormEncode translation if it finds language in session. This function is the only i18n API that the controller is aware of and it's called internally, so there's no way to change this without overriding controller methods. That is, currently FormEncode translation is only set when there's an Accept-Language match. Shouldn't setup_i18n() also set FormEncode translation if there's language in session? yes I think it should. OK. Here's a ticket for this http://trac.turbogears.org/ticket/2335 There's also a patch. -- Timur Izhbulatov — www.timka.org -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Where is current development work happening?
yea, the 2.1 work is happening on hg.turbogears.org which is bitbucket ;) On Thu, Jun 18, 2009 at 10:03 AM, Bill5107william.ri...@pw.utc.com wrote: I had an issue with my quickstart app, so I figured I'd make sure I had the latest software and found that I cannot tell where the latest code is. I gather the project is still active, but where should we look for the most recent releases and the development repositories? Has TG moved to mercurial? (I see bitbucket projects, for example) -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: The future of TurboGears
Yea, I've been very focused on a work project the last couple of months, which will be good for TurboGears, but it's taken a lot of my focus away from the framework itself. If we could have some volenteers to help with a couple of important tasks it would help a lot: * Get beta.turbogears.org into final usable shape * Help push the TG2 docs forwared * Now that 2.0 final is out I want to migrate the 2.0 code to bitbucket and close out the use of SVN for tg2 On the coding side: * We need a changelog for 2.1, and more tests for routes, config, and tw integration. On Wed, Jun 17, 2009 at 4:10 PM, Derick Eisenhardtderick.eisenha...@gmail.com wrote: So, TG2 finally has a stable release. However, it's release has sadly come out to little fan fare as far as most of the web is concerned. I'm worried by the current state of advertising/marketing and documentation, that what there is available currently has very little appeal to the majority of web developers out there. For TG2 to make any real traction it's going to have to appear to be the best of breed web development environments. As far as I can tell the only folks currently interested are those of us who have previously been using TG1, are hard core python fans, or are already sold on the idea of distributed/modular development (WSGI). That unfortunately leaves Turbogears with a somewhat niche audience. Django grew it's user base by advertising to people that it was the best, easiest to learn and use web development platform and better than Ruby on Rails. Their community seems to still be growing at rapid rates, while I've seen hardly any difference in new users around here since TG2 went final. At the end of the day, the average web developer doesn't care what platform they're using, or how it works...they just want the quickest and easiest method to get what their site running and doing what they want. Currently, TG2 still has a good bit of a learning curve. And I'm sorry to burst anyone's bubbles, but we DO NOT in any way shape or form have the best documented web development platform. And until it's retardedly easy for someone who has never programmed in Python, barely ever used the MVC model before, and knows nothing of command lines to jump in and make their first TG site in less than an hour, it's going to remain a niche audience. Beyond that our site is a bit of a joke currently. We're not even self hosting as far as I can tell. Now I know there's http://beta.turbogears.org out there, and I know folks are working on the Pages CMS. But we really should have had all that up before 2.0 went final. It's truely amazing how much a person will judge you're product simply on the the looks of your website alone, especially when the product is a web development platform. Furthermore, ToscaWidgets is dead in the water as far as I can tell and it's widget selection is sparse at best. It is absolutely imperative that TG have a full-featured widget toolkit built-in by default and it be just as well documented as any other aspect of the platform. TG1 had fairly good integration with MochiKit, but TG2's current stance appears to be you can either use this basic Tosca stuff someone threw together and then let stagnate for a year, or go out and find a real widget library (jQuery, Dojo, etc), but you'll have to figure out how to use it by yourself. And that is the exact opposite of the position we should be portraying to new users...if people want that situation, why not just use plain ol' Pylons? I hope I have not offended anyone here today, I'm just trying to tell it like it is. I implore you to not spend so much time on adding new features to 2.1 and focus on getting these core problems taken care of first and foremost. Please please please make 2.1 all about polish. I'd really love to talk to fellow developers and when I say I use Turbogears, they don't respond with a huh? what's that? -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Strange redirect() behavior
Well, it would be pretty easy to write a redirect function that
doesn't call url, but we wanted backwards compatability.
If you want one right now, I think you should be able to make one and
put it in your lib directory very easily.
heck you could just:
raise HTTPFound(/)).exception
and if you're on python 2.5 or above and can have newstyle classes
that are also exceptions you can just:
raise HTTPFound(/)
--Mark
On Fri, May 29, 2009 at 3:45 PM, Christoph Zwerschke c...@online.de wrote:
Bryan Koroleski schrieb:
To redirect to the root of the site, I previously used redirect('/'),
and to redirect to the root of the application, I used redirect(url
('/')). Upon inspection of the redirect function, I've found that url
is automatically applied to any url passed into the redirect function.
This makes redirects to same-domain-non-TurboGears paths painful.
But actually that was the case since TG 1.0 already.
-- Christoph
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: TG Registration extension
You should take a look at some extensions in tgext on google code. Silverplate was a registration module for tg2 but I think it's been left behind a bit, but it might serve as a good place to look for some stuff. If you want we can get you access to the tgext google code project, as I'd recomend putting your code in the tgext namespace too. Though I'm thinking perhaps it would be nice to move the tgext stuff to bitbucket to go with the main tg sources. Any objections to moving tgext projects to bitbucket? --Mark Ramm On Fri, May 29, 2009 at 4:14 PM, Alexandru Marinescu almarine...@gmail.com wrote: Hi, I'm currently working an a registration extension(provide API to register users inside a TG application - API + registration forms). Your opinion on this would be of great help for me. To make thinks easier to understand you can check diagram of what I'm proposing as a starting point for the extension's workflow at the following address[1]. The extension is in very early stage of development, but I'm hoping that in a week to have a working version. After the extension matures a bit I would like to work and an extension to provide OpenID authentication inside TG application. This second extension would use some of the things defined by the registration extension. I would like to know what would you like to see in an extension like this. Kind regards, Alexandru Marinescu -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Ok, 2.0 is out, what about turbogears 2.1?
There has been lots of great work done on the 2.1 code in hg.turbogears.org, chris has rewritten the dispatcher, Jorge has a new much slimmer TurboJson alternative for automatic jsonification, and there's quite a few other performance enhancements. There was talk about a new YAML based config system, new quickstart template code, pylons trunk (1.0) code support, explicit support for site--components, etc. I'd like these things to be done as soon as possible, but I think releasing a 2.1 alpha with what we have now would be valuable. And I think we should keep a clean trunk so that we can release 2.1 whenever the time is right. So, I think that all potentially disruptive work should be done in hg branches and then merged back to the trunk as the projects are completed. I also think we should try to get a 2.1 alpha ready by somewhere between the 5th and 12th of June. This will give 2.0 some time to settle down into people's bones, but will also get a 2.1a1 out before the summer doldrums sets in. And it would be great to get lots of the shiny goodness that's in 2.1 already out into people's hands to try out. Ultimately I think it's better to release the work that's done now sooner rather than later, and to continue to have more and smaller releases. So if the new features are not ready, in time for 2.1 they will be ready for 2.2 ;) -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TurboGears 2.0 final announced
The long wait is finally over! I am happy to announce the release of TurboGears 2.0 finalhttp://turbogears.org/2.0 . This release is the product of a lot of work by the whole TurboGears team, and we're very happy to have a final stable release. TurboGears 2.0 final includes all kinds of goodies for those making web applications, from one of the most powerful and flexible Object Relational Mappers available in any language, to a powerful and flexible template system. But just as important as the quality of the parts, is the out-of-the-box integration to help get you started quickly: - We have quickstart template that helps get you going quickly with everything you need: from sample templates, to sample controllers and tests. - We have an extensible user/groups/permission system that you can easily configure into your app when quickstarting a project. - We have zero config needed support for development database backed by SQLite - We have a working admin system for editing your database while your app is in development - Our admin system is extensible and reusable as a component of your application There's lots more. But we also don't think that out of the box defaults should become constraints on our users. TurboGears 2 is designe to get you started quickly and get out of your way when you know what you want. So, a trivial configuration change lets you use DB2, or Oracle, or SQLServer, and everything we've wired up for you is easy enough to customize or replace. For example, we support configs for three major python template engines out of the box, and you can easily make your own render function to handle anything else you want. One of the goals of TurboGears 2 http://turbogears.org/2.0 is to use standard python components, that are valuable in all kinds of other contexts, so you are not tied into one monolythic system. Learning SQLAlchemy can help you write command line tools, GUI apps, web-services that don't use a framework; Genshi is valuable when generating all kinds of xml data for interchange between systems; the beaker is a great caching system that's valuable in all kind of web contexts, etc. TurboGears 2 http://turbogears.org/2.0 final is just now comming out, but it's already in production use at places like ShootQ, RedHat (for a large set of Fedora infrastructure projects) and many other places. And we're already looking forward to a few more high profile TG2 deployments in the next few weeks. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: mutiple database question
The actual connection is done via setup_sqlalchemy in the AppConfig object see configuraiton.py for details. Basically, you can create a subclass of AppConfig.py with a new setup_sqlalchemy method that does whatever you want. We *should* document this in our standard sphinx documentation, but it seems that everybody has been pretty busy. --Mark Ramm On Mon, May 25, 2009 at 4:33 AM, dakila dak...@gmail.com wrote: yes, I read it, sorry if its not obvious to me. But still have no idea regarding the next steps after creating a second MetaData. Basically how would I create the second sqlalchemy.url and other stuff to indicate the second database to connect to, etc. On May 25, 1:32 pm, Jorge Vargas jorge.var...@gmail.com wrote: On Sat, May 23, 2009 at 9:09 AM, dakila dak...@gmail.com wrote: Hi All, How do I connect to two databases in tg2? I have been reading the information in [1,2], but have no idea how to do it in a quickstarted tg2 application. Did you read the comments in the model.__init__.py it's pretty much setup for you. Just create a second metadata [1]http://wiki.pylonshq.com/display/pylonsdocs/Using+SQLAlchemy+with+Pylons [2]http://www.sqlalchemy.org/docs/04/session.html#unitofwork_contextual_... Regards, Dax -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 status.
The 2.0 development is in a 2.0 branch in svn, and all work in that branch has been bugfixes. We should do a release out of that branch very soon because I *need* one myself, and I won't let anything but code stability issues block that from happening, and the 2.0 code base has been stable, so I think that there should not be an issue with making a release. We can continue to improve our marketing materials forever, but we can't keep postponing the release forever ;) --Mark Ramm On Sat, May 23, 2009 at 10:07 PM, Luciano Ramalho rama...@gmail.com wrote: Hello, I am very glad to see TG2 nearing it's release, but I wonder what the pace is at this time, since the homepage [0] still mentions an RC1 release dated March 23 with final release in the next couple of weeks. However, Trac [1] shows no activity on trunk for the last two months. I've found a tg 2.1 repo by Mark Ramm on Bitbucket [2] and that has more recent activity. But where is the actual work being done for the 2.0 release? Have you decided to skip that release an go straight to 2.1? I was at PyCon 2009, talked to Mark once during the sprints, and was very happy to learn that TG2 is going well, but the lack of apparent progress is worrisome. I believe it's very important for the Python web story that TG2 succeeds, but you need to do better in the communications front! Best regards, Luciano Ramalho [0] http://www.turbogears.org/ [1] http://trac.turbogears.org/browser/trunk [2] http://bitbucket.org/mramm/tg-21/ -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Supported Template Engines
I am fine with adding them to quickstart in 2.1 as an option. In fact I think that could be very useful. I think there are some concerns about the complexity of the QS template, and I think that we do need to be mindful of that, but supporting Mako out of the box is an important goal. --Mark Ramm On Mon, May 18, 2009 at 10:24 AM, percious ch...@percious.com wrote: I feel that the mako support is just as good as genshi, in terms of the framework code. I primarily use mako for it's concise syntax and speed. I have built master/index for mako and would be happy to publish them, but I have received a bit of pushback from the TG2 team whilst recommending adding them to the quickstart template (no one wants to be responsible for their maintenance, although I volunteered for the job). The mako version of quickstart is 400% faster for the index page, and it speeds up the Admin pages by about 50%. cheers. -chris On May 14, 4:07 pm, cd34 mcd...@gmail.com wrote: Mako and Cheetah seem to have rudimentary support, but, aren't well supported. Genshi seems to be very well supported, but, quite a bit of the development points to jinja2. Is jinja2 going to be the primary engine? or should I stick with genshi? Jinja2 has some nice features that I would like to use, but, I would prefer to use whatever the primary engine is that TurboGears is going to stick with. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Supported Template Engines
This question is fine on this list. I know it would be nice to make it super obvious what list what message should go on, but this message asks a question about TG2 behavior present, and about the future, so it really spans both lists. --Mark Ramm On Fri, May 15, 2009 at 10:15 AM, cd34 mcd...@gmail.com wrote: On May 15, 12:24 am, Jorge Vargas jorge.var...@gmail.com wrote: On Thu, May 14, 2009 at 6:07 PM, cd34 mcd...@gmail.com wrote: I would prefer to use whatever the primary engine is that TurboGears is going to stick with. TG is about flexibility. PS: this message doesn't really belongs to turbogears-trunk What list should be used to ask about the future direction of turbogears? Based on the description of this group, it seems this is the place to ask: Description Discussion of activity on the TurboGears trunk -- bug reports, new features, etc. all to appear in the future TurboGears versions. But, I'll stop posting in trunk based on your request. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: expose('json'), TurboJson and TG2.1
Here's my vote: 1) Create a new package with a new name. 2) use that package with the new name by default in tg 2.1 continue to use TurboJson in tg 2.0 and 1.x and allow 2.1 to use TurboJson for backwards compatability if people want. On Sun, Apr 26, 2009 at 12:32 PM, Jorge Godoy jgo...@gmail.com wrote: If you're forking it, then I believe that SO support -- as well as support for old versions of SA -- are interesting. If you're keeping it tied to TG2, then I don't see a reason to fork it into a separate package. What I mean is: if decoupled, then maintaining current features is needed -- even though they are not supported by TG2; if not decoupled then lets not create a new dependency. -- Jorge Godoy jgo...@gmail.com On Sun, Apr 26, 2009 at 5:54 AM, Jorge Vargas jorge.var...@gmail.com wrote: Hello Everyone here is an update on my work, and at this point I need feedback, to see where we are going to end up. First of all a quick summary. TurboJson provides the following 1- a buffet API 2- a JSONEncoder subclass that implements methods for 3- any object with __json__ 4- date and datetime objects 5- decimal.Decimal 6- SQLObject 7- SQLAlchemy (0.5, 0.4 and 0.3) 8- SQLAlchemy ResultProxy and RowProxy (the objects used by sqlalchemy.sql) 9- any third party object with the @jsonify.when() decorator. 10 - priority overrides 11- TG2 currently still uses the is still using the buffet rendering API. Therefore at this point we could get rid of TurboJson and incorporate that functionality directly into TG2 (tg/json.py for example) but I think this extra library is good as standalone as it could provide a default set of types for use outside TG, so I think it should live on as a tiny api (like webflash), although by this point I think it should be renamed. The patches. technically it's 2 patches one for tg2.1 and another for TurboJson although the second is pretty much a complete rewrite. $ cat jsonify.py jsonsupport.py | wc -l 93 $ svn diff jsonify.py jsonsupport.py | wc -l 200 The state of my patch, What is ok - it removes 1 and 11 from tg2.1 - It provides 2 but without rule dispatch, it simply uses a subclass with a default method that tests the object for types and return the proper conversion. - it provides conversions for 3,4,5, 8 and 7 for SA0.5 What is missing? SO (6) - There is no implementation* for SQLObject, but could be added back in easily SA 0.4 and SA 0.3 support (7) - I haven't tested this code with older version of SA Third Party Object (9) - This is not implemented yet* priority overrides (10) - It is my understanding this is a rule-dispatch extension to allow resolution of conflicting rules. * This could be easily implemented I'm just not sure if it's worth it but the procedure will be simply to extend GenericJSON to provide SO and expose that class inside TurboJson and to write some documentation on how to do this. And then provide a hook for replacing the default implementation or simply change the public api from TurboJson to be more flexible in the TG2 part I'm having only 2 test failing. 1- Should be totally unrelated and seems to me like a bug I uncovered with this change test_template_override 2- This is really important what should render_json do when the objects in template_vars are not valid JSON? currently the test fails with a generic simplejson encoding error (TypeError) which if run on a real server should send a 500 error, but it is not happening. So in general I think we should either a- fork TurboJson into another package (names welcome) which will only support what it supports now (with the extending pending, but with a small change in the API, that will probably make it equal to simplejson.dumps) how about VargasJson hehe j/k b- patch TurboJson with my code and add a TG1 compatibility layer. IMO my patch/fork covers 95% of the interesting use cases and with the API change for extending it. it should over that 5% missing, since we should drop support for SO, SA4 and SA3 since TG2 doesn't supports them. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Subcontroller missing
You can use any object as a subcontroller, there's generally no need to have a common base. So just inherit form object, or create your own base. On Apr 24, 6:41 am, Scripper scrip...@gmail.com wrote: Or just have to create that myself, it is not there by default? On 24 Apr., 12:33, Scripper scrip...@gmail.com wrote: Hallo, just take a shot at the lib.base and found no more Controller that means i can't use the Subcontroller anymore? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 status.
On Mon, Apr 20, 2009 at 8:06 AM, Florent Aide florent.a...@gmail.com wrote: On Mon, Apr 20, 2009 at 11:42 AM, Diez B. Roggisch de...@web.de wrote: One major thing that I'd like to see worked out in 2.1 is better handling of the way we load and render templates. In my mind we should switch to using the native template loaders from genshi, mako, etc -- or we should create a separate dotted notation loader package that contains just the code that loads templates based on python path like notation. There are advantages to both ways of doing things, but we need to choose between them and then commit to that path. I have worked a lot on this and already added some more template loader support in 2.1 Dotted names support is the easiest way I see to easily support extension (think Pages)... I am also in favor of moving the template (moving and rendering) in another subpackage not directly in tg.core. In this I would like to decouple tg from pylons.templating.render_xx() I'm not totally sure why search paths wouldn't work for extensions like pages. You have to use actual paths, but it's very easy to overide the template of an extension by putting something higher up the list of paths to check (like in your app code). I've used this in a couple projects where we had re-usable chunks and it worked out well. But I'd believe that there's something I'm missing, just not sure what it is yet ;) Unless what's missing is support for extensions to be zipped eggs --Mark Ramm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 status.
Yea, we won't want to drop dotted name support any time soon even if we do decide to go the other route, but we might want to deprecate it at some point. On Mon, Apr 20, 2009 at 3:41 PM, Florent Aide florent.a...@gmail.com wrote: On Mon, Apr 20, 2009 at 8:20 PM, Mark Ramm mark.mchristen...@gmail.com wrote: I'm not totally sure why search paths wouldn't work for extensions like pages. You have to use actual paths, but it's very easy to overide the template of an extension by putting something higher up the list of paths to check (like in your app code). I've used this in a couple projects where we had re-usable chunks and it worked out well. But I'd believe that there's something I'm missing, just not sure what it is yet ;) Well, I also think of tg1 -- tg2 migration. TG1 users have dotted names all around the place. Just a question of migration path really. I'm sure we can desing something that drops dotted names support altogether... we just need to decide what we want. If we go the non dotted path way we at least need to document this and tell people about the migration way. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] 2.0 final work
I've gone through all the tickets that I could find, updated the eggs in the 2.0 final index, and closed what tickets I can. We need to figure out what we're doing about TW, also I'm thinking about updating the zope.sqlalchemy requirement in quickstart so that we don't get bit by the bulk updates not being committed issue that has been reported a couple of times on the mailing list. Any other patches or quick updates that ought to happen before 2.0 final is released? Also, if you want feel free to test out the new eggs at http://turbogears.org/2.0/downloads/2.0final/ -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TG2 status.
I had set aside saturday to work on finalizing the 2.0 release, but unfortunately I was both sick, and had internet connectivity problems. I'll be working on release stuff again Monday and Tuesday nights. Any help we can get would be great. I'm also thinking about putting out a 2.1 alpha next week, since there are some significant performance enhancements there already, and I'd like us to move forward on the dispatch refactoring that chris has done quite quickly, because I think it will be easier to support in the long run. One major thing that I'd like to see worked out in 2.1 is better handling of the way we load and render templates. In my mind we should switch to using the native template loaders from genshi, mako, etc -- or we should create a separate dotted notation loader package that contains just the code that loads templates based on python path like notation.There are advantages to both ways of doing things, but we need to choose between them and then commit to that path. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 in HG
Sure, that would work, and would probably get us up and running on the new server sooner. Let's see what elpargo has to say about all this as he was working on this stuff before he left for vacation ;) --Mark Ramm On Mon, Apr 13, 2009 at 3:23 PM, Christoph Zwerschke c...@online.de wrote: Mark Ramm schrieb: Hmm, I think the plan has been to move trac and hg to the new server eventually and have trac conect to hg directly again then. But then we will lose the links to the svn revisions in the old tickets. Wouldn't it be cleaner to set up a separate trac connected to hg for TG2, without all the old tickets, and keep the old trac connected to svn for work on the TG 1.x branch? -- Christoph -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 in HG
Hmm, I think the plan has been to move trac and hg to the new server eventually and have trac conect to hg directly again then. I feel somewhat conflicted about this. I like that bitbucket keeps track of branches for us, and that it makes it easy for anybody who wants to to publish new branches. But I think the ticket tracker is a bit rudamentary. --Mark Ramm On Mon, Apr 13, 2009 at 1:20 PM, Christoph Zwerschke c...@online.de wrote: Mark Ramm schrieb: Yea, that's the official development version for 2.1. I'll give you push access. And for those who don't have push access, feel free to branch make changes, and then ping this list for one of us to merge your changes back in. Ok, thanks. But what about issue tracking? Our TG trac is still bound to the SVN repository, so linking to changesets in tickets will not work any more. Will we make a new trac for TG2 or use the bitbucket issue tracker? I think we would benefit from creating a new issue tracker for TG2 anyway, because most of the old tickets are irrelevant for TG2 now. -- Christoph -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Double dot in archive name
I'll check it out. On Wed, Apr 8, 2009 at 5:16 AM, Christophe de VIENNE cdevie...@gmail.com wrote: Hi, The rc1 and final packages have a double dot in the filename : TurboGears2-2.0..tar.gz TurboGears2-2.0rc1..tar.gz It is a bit disturbing.. Regards, Christophe de Vienne -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: callable for validator-argument of @validate?
No objection from me. 2.1 lives in hg now, and the dispatch refactor is something that I want to push forward sooner rather than later, so it may not be long between 2.0 and 2.1. Granting you push access to that repo now. ;) On Tue, Apr 7, 2009 at 9:28 AM, Diez B. Roggisch de...@web.de wrote: Hi, I just noticed that TG2 lost the capability to pass callables as validators to the @validate-decorator. This is a major drawback, as it prevents the dynamic selection of forms to validate. I guess it's to late for TG2.0, but I'd like to implement the feature for TG2.1 if nobody opposes. Diez -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 final status
I assigned that ticket to myself, and I'll get a fix in and update the index at lunch. ;) --Mark Ramm On Mon, Apr 6, 2009 at 12:36 AM, Sanjiv Singh singhsanj...@gmail.com wrote: Hi Mark, I found another minor issue in rc1 http://trac.turbogears.org/ticket/2297 can this make it to 2.0final? regards Sanjiv On Mon, Apr 6, 2009 at 7:25 AM, Mark Ramm mark.mchristen...@gmail.com wrote: Oops, I also indended to give you the URL for the new index. This should now work: easy_install -i http://turbogears.org/2.0/downloads/2.0final/index/ tg.devtools Let me know if you have any troubles with it. The changes from rc1 include: 1) getting the routing args validatable to match the tg1 behavior. 2) updating the toscawidget and tw.forms eggs to fix 2 issues reported on the list. Special thanks goes to Percious for both of these!. --Mark Ramm On Sun, Apr 5, 2009 at 9:53 PM, Mark Ramm mark.mchristen...@gmail.com wrote: Just uploaded a 2.0 final index which I hope will work out for us. We're lagging behind where I thought we would be in terms of marketing material updates. Some of this is my fault for forgetting a couple of commitments I had for this weekend, and some of it is the fault of my failing laptop, which required some work to get into a state where I could retrieve the keys to the server so I could upload stuff. I'll be working on marketing materials tomorrow night, but I'll probably not actually push 2.0 final for a couple days because I want to get us to a state where we can give a very good impression on 2.0 final. But if the 2.0 final index works for everybody I may do a soft launch of 2.0 final tuesday, hopefully with full marketing blitz on thursday or friday. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TG2 final status
Just uploaded a 2.0 final index which I hope will work out for us. We're lagging behind where I thought we would be in terms of marketing material updates. Some of this is my fault for forgetting a couple of commitments I had for this weekend, and some of it is the fault of my failing laptop, which required some work to get into a state where I could retrieve the keys to the server so I could upload stuff. I'll be working on marketing materials tomorrow night, but I'll probably not actually push 2.0 final for a couple days because I want to get us to a state where we can give a very good impression on 2.0 final. But if the 2.0 final index works for everybody I may do a soft launch of 2.0 final tuesday, hopefully with full marketing blitz on thursday or friday. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: The .tar package of Turbogears2 is broken
will do. Thanks for the report! On Thu, Apr 2, 2009 at 3:35 AM, Christophe de VIENNE cdevie...@gmail.com wrote: Hi, A .tar version of the TG2 source is present in the current download directory : * http://www.turbogears.org/2.0/downloads/current/TurboGears2-2.0rc1..tar When easy_installing TG, setuptools download it instead of the .tar.gz (which is good), and one cannot run its tg application anymore : File /home/cdevienne/ws/hrportal/lib/python2.5/site-packages/TurboGears2-2.0rc1.-py2.5.egg/tg/__init__.py, line 57, in module from tg.wsgiapp import TGApp ImportError: No module named wsgiapp It would be nice if it is removed. Thanks, Christophe -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: OperationalError: (OperationalError) no such table: tg_user
I believe the documentaiton covers setup-app, which should just work. If there's something missing in some doc, it would be great to know where you didn't find the info you wanted so that we can add it. ;) --mark ramm On Wed, Apr 1, 2009 at 2:45 PM, Paul Rigor paulri...@gmail.com wrote: Thanks! That command setup the default db... I'm now getting an authentication failure even though I'm using the default websetup/bootstrap values. I'll dig further into this... Will there be documentation clarifying application quickstarts which enable authentication feature? Thanks, Paul On Mar 31, 6:53 pm, Mark Ramm mark.mchristen...@gmail.com wrote: Try the command: paster setup-app development.ini then if you want to edit what happens when that command runs try editing websetup.py --Mark Ramm On Tue, Mar 31, 2009 at 2:12 PM, Paul Rigor paulri...@gmail.com wrote: Hi, This is regarding TurbeGears2 and my attempt to use catwalk (via / admin) on a barebones system. I created a skeleton project with authentication enabled. I'm using the default sqlitedb... My qestion: Is there an interface to create admin accounts or do I need to perform this via command-line, ie, sqlite CLI? Currently, I receive the following error when serving both development and test configs... OperationalError: (OperationalError) no such table: tg_user u'SELECT tg_user.password AS tg_user_password, tg_user.user_id AS tg_user_user_id, tg_user.user_name AS tg_user_user_name, tg_user.email_address AS tg_user_email_address, tg_user.display_name AS tg_user_display_name, tg_user.created AS tg_user_created \nFROM tg_user \nWHERE tg_user.user_name = ? \n LIMIT 2 OFFSET 0' ['manager'] I'd gladly appreciate any insight/tips! thanks, Paul On Feb 28, 12:24 pm, Jorge Vargas jorge.var...@gmail.com wrote: On Sat, Feb 28, 2009 at 2:22 PM, Gustavo Narea m...@gustavonarea.net wrote: On Wednesday February 25, 2009 20:18:56 Sanjiv Singh wrote: I dont get that error. Although the tests fail with one error http://paste.chrisarndt.de/paste/599585def18b40cea02b07d2c8393cc8 Thanks, Sanjiv! I get that in b6 too, so I created the relevant ticket: http://trac.turbogears.org/ticket/2243 For the record this is a known issue. At least by me i'm not sure if we had a ticket. I believe the way our db is setup in test.ini is wrong. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog:www.compoundthinking.com/blog -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: OperationalError: (OperationalError) no such table: tg_user
Try the command: paster setup-app development.ini then if you want to edit what happens when that command runs try editing websetup.py --Mark Ramm On Tue, Mar 31, 2009 at 2:12 PM, Paul Rigor paulri...@gmail.com wrote: Hi, This is regarding TurbeGears2 and my attempt to use catwalk (via / admin) on a barebones system. I created a skeleton project with authentication enabled. I'm using the default sqlitedb... My qestion: Is there an interface to create admin accounts or do I need to perform this via command-line, ie, sqlite CLI? Currently, I receive the following error when serving both development and test configs... OperationalError: (OperationalError) no such table: tg_user u'SELECT tg_user.password AS tg_user_password, tg_user.user_id AS tg_user_user_id, tg_user.user_name AS tg_user_user_name, tg_user.email_address AS tg_user_email_address, tg_user.display_name AS tg_user_display_name, tg_user.created AS tg_user_created \nFROM tg_user \nWHERE tg_user.user_name = ? \n LIMIT 2 OFFSET 0' ['manager'] I'd gladly appreciate any insight/tips! thanks, Paul On Feb 28, 12:24 pm, Jorge Vargas jorge.var...@gmail.com wrote: On Sat, Feb 28, 2009 at 2:22 PM, Gustavo Narea m...@gustavonarea.net wrote: On Wednesday February 25, 2009 20:18:56 Sanjiv Singh wrote: I dont get that error. Although the tests fail with one error http://paste.chrisarndt.de/paste/599585def18b40cea02b07d2c8393cc8 Thanks, Sanjiv! I get that in b6 too, so I created the relevant ticket: http://trac.turbogears.org/ticket/2243 For the record this is a known issue. At least by me i'm not sure if we had a ticket. I believe the way our db is setup in test.ini is wrong. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TG2 in HG
Today I learned that Python itself will be switching from SVN to HG, and we can't be left behind, so here are some semi-official HG branches for TG2, and releated projects. Eventually these will be moved to the turbogears.org domain, but for now bitbucket should work fine. Feel free to setup a bitbucket account, publish additonal branches and otherwise make use of mercurial to work on various things. http://bitbucket.org/mramm/tg-21/ -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Turbogears 2.0 Release Candidate 1 now available!
http://turbogears.org/2.0/docs/main/DownloadInstall.html Those instructions reference downloads/current which has been removed. It presumably should refer to downloads/2.0rc1 instead. The current directory was accidentally linked to a non-existant rc (without the 1) directory, which apparently produces no errors but also does not work. I've fixed that, and all is good with the normal download instructions again. Thanks for the quick catch. --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Problem with validate decorator in TG 2.0rc1
Was this not also true of TG 1? I have some memory of having to convert url params manually there too, but it's been a while ;) --Mark Ramm On Tue, Mar 24, 2009 at 3:23 AM, Christoph Zwerschke c...@online.de wrote: percious wrote: I can probably fix this next week with the dispatch refactor. I will take a special note of it. That would be great. After all, I consider this a bug, so it should not fall under the feature freeze. It also shows that our test suite needs some improvement since it did not catch such a basic issue. -- Christoph -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSOC idea discussion: TurboGears Content Management System
Wow, that is really nice!
One other worth looking at in general when thinking about plugable
components is the Component Architecture from the zope project, which
seems way worse than it actually is.
I think they overuse it in many places, and it creates some issues
because of that, but it's a solid component framework that's been
tested in years and years of production use, which says something.
--Mark Ramm
On Tue, Mar 24, 2009 at 2:39 AM, Michael Brickenstein
brickenst...@mfo.de wrote:
Hi!
Regarding components:
You should have a look at components in RUM:
I don't know, if that matches your concept of a component, but
it's completely pluggable.
http://docs.python-rum.org/developer/modules/component.html#module-rum.component
Most things in rum are components:
wsgiapp.py: controllerfactory = Component('rum.controllerfactory',
default='default')
wsgiapp.py: repositoryfactory = Component(rum.repositoryfactory,
default='default')
wsgiapp.py: viewfactory = Component('rum.viewfactory',
default='default')
wsgiapp.py: router = Component('rum.router', default='default')
wsgiapp.py: policy = Component('rum.policy', default='default')
wsgiapp.py: jsonencoder = Component('rum.jsonencoder',
default='default')
wsgiapp.py: translator = Component('rum.translator',
default='default')
At the moment this is tied to rum apps, but it shouldn't be a problem
to make it fit into different settings.
Another point, which might be interesting for you, is that the next
version of RUM will contain a security policy: Alberto's latest
marvel.
http://hg.python-rum.org/TgRumDemo/file/688e9ea77be2/tgrumdemo/policy.py#l1
This might also fit into your CMS.
Michael
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: Problem with validate decorator in TG 2.0rc1
Ok, sounds like it's a bug then, and something we can fix even post feature-freeze. Thanks! --Mark Ramm On Tue, Mar 24, 2009 at 7:03 AM, Christoph Zwerschke c...@online.de wrote: Mark Ramm schrieb: Was this not also true of TG 1? I have some memory of having to convert url params manually there too, but it's been a while ;) No, this works in TG1, I've been using it all the time there. -- Christoph -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] WSGI sprint at pycon
Pylons, Repoze and TG are hooking up in a three-way sprint at pycon this year, and we're in an open relationship so anybody who's interested in hot-wsgi-action can show up and sprint on anything wsgi related. ;) The plan is to increase the levels at which we work together, and to improve our respective frameworks at the same time. Should be a lot of fun, and if you can't make it to pycon, feel free to hook up with the sprint over IRC. I expect we'll have folks on #turbogears, #repoze, and #pylons, and we may make a sprint specific room, so stay tuned. http://us.pycon.org/2009/sprints/projects/wsgi/ -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TG 2 in svn
We now have 2.0 branches for both tg.devtools and the main tg code. These branches are ONLY for bugfixes, docstring improvements and other changes that belong in the 2.0 release. That means 2.1 work can get started in trunk right now. :) And in fact there's already a 2.1 feature that have landed there ;) Process recommendation: If you're fixing a bug in 2.0 fix it in trunk and then merge that change over to the 2.0 branch. Thanks! -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Problem with validate decorator in TG 2.0rc1
Ouch, this sounds bad.
I will look into it as soon as I get a break at work.
If somebody else could take a look that would be great!
On Mon, Mar 23, 2009 at 9:48 AM, Christoph Zwerschke c...@online.de wrote:
Am I doing something fundamentally wrong or is there a problem with the
validate decorator in TG 2.0rc1?
I'm using it in the very basic way as described here:
http://turbogears.org/2.0/docs/main/Validation.html#validating-arguments-without-form-widgets
To reproduce the problem, quickstart an application, add the following
at the top of controllers/root,
from tg import validate
from formencode import validators
and change the index method of the root controller like this:
�...@expose('foo.templates.index')
�...@validate(validators=dict(nr=validators.Int()))
def index(self, nr=None):
...
Now run the application and surf to http://localhost:8080/index/1.
The validator should pass, but I'm getting this:
TypeError: index() got multiple values for keyword argument 'nr'
-- Christoph
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: Problem with validate decorator in TG 2.0rc1
Actually, not so bad. You can validate get parameters, or post
parameters but not URL args.
This is something we need to work out for 2.1 because it's now come up
two or three times.
On Mon, Mar 23, 2009 at 9:48 AM, Christoph Zwerschke c...@online.de wrote:
Am I doing something fundamentally wrong or is there a problem with the
validate decorator in TG 2.0rc1?
I'm using it in the very basic way as described here:
http://turbogears.org/2.0/docs/main/Validation.html#validating-arguments-without-form-widgets
To reproduce the problem, quickstart an application, add the following
at the top of controllers/root,
from tg import validate
from formencode import validators
and change the index method of the root controller like this:
�...@expose('foo.templates.index')
�...@validate(validators=dict(nr=validators.Int()))
def index(self, nr=None):
...
Now run the application and surf to http://localhost:8080/index/1.
The validator should pass, but I'm getting this:
TypeError: index() got multiple values for keyword argument 'nr'
-- Christoph
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Quickstart and DB creation
Look, it was my choice to make this happen, and I stand by it.
We can tell people installing pages to update websetup.py as
nessisary, and the people reading the python magazine article can use
code that just works.
And from my perspective the code inside the quickstart--that we intend
for people to use and modify is part of our features, and this as a
new feature should have been covered by the feature freeze. All this
talk about API changes, public API changes, etc is besides the point.
This is a new feature, and so should be covered by the feature freeze.
But I take responsibility, this whole thing is my fault, because I
told Chris to go ahead without thinking through the consequences. I
made a mistake, and I totally take responsibility for that.
I think the sky will not fall either way, and I am definitely one of
the ones who wanted the functionality, but I also want the python
magazine article to give people a positive view of TG2.
Either choice was going to cause some people problems, and solve other
problems, so we were never going to have everybody happy, heck we were
never going to make me happy, because I want two conflicting things ;)
So, with all that said, let's not fight about what constitutes and API
change, and let's throw any stones than need throwing my direction.
I'm a pretty good catch, and if not I can take it.
Thanks!
On Mon, Mar 23, 2009 at 10:52 PM, Jorge Vargas jorge.var...@gmail.com wrote:
This has taken way too long and it's way out of topic. I won't bother
answering inline anymore. If you want to think it's api change then
fine go ahead this is no api at all as you don't even need quickstart
to have a TG2 project. If you keep insisting it changes the API fine I
won't argue about that.
In the meanwhile we have a broken tgext.pages (see the thread from
GSOC for the first user figuring that out)
But don't worry when people complain about how inflexible websetup is
we'll point them to this thread.
On Mon, Mar 23, 2009 at 2:21 PM, Gustavo Narea m...@gustavonarea.net wrote:
And apologies, I slipped in that part while trying to trim the email.
My thoughts on your proposal:
1.- It'd still be an API change, it just happens to be smaller: no new
modules, but two new functions.
whatever, you are making a huge deal out of splitting a function into
3 logical functions which by the way everyone already does.
2.- It'd still outdate some texts, like mine where I say something like Add
the contents of Listing N right before DBSession.flush() and commit().
which are probably way unflexible, and again it's totally fixable.
15 def setup_app(command, conf, vars):
16 Place any commands to setup {{package}} here
17 load_environment(conf.global_conf, conf.local_conf)
18 setup_schema(command, conf, vars)
19 bootstrap(command, conf, vars)
20 DBSession.flush()
21 transaction.commit()
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Turbogears 2.0 Release Candidate 1 now available!
The TurboGears Development team is proud to announce TG2 Release Candidate 1 just in time for pycon. This is a huge milestone for us, and I'm personally very proud that we've made it here. This is the culmination of a long, challenging, and fun, process of re-creating TurboGears to solve many of the problems of next generation web frameworks using a whole set of amazing python components that will be around and supported for years. With this release, I think we've proved that it's possible to scale these next generation of webframeworks up to solve complex enterprise problems with multiple legacy databases, and down to creating rapid prototypes. And 2.0 is going to provide a great platform for the future of the TurboGears project. We've added major industrial strength features like a scalable and easy to use session manager, a full transaction management system, and much more -- all while reducing the total number of lines of code in the project, and creating reusable components that are now a shared part of the python WSGI Web ecosystem. Thanks everybody who contributed! I'm also very happy to see that some very good work is already going into creating add on components (like a lightweight cms) for TG2 and work has already started on making this even easier in tg To download 2.0 RC 1, simply follow the instructions here: http://turbogears.org/2.0/docs/main/DownloadInstall.html There are just two small bugfixes in RC1, but you're interested in the details, take a look at the changelog: http://trac.turbogears.org/wiki/2.0/changelog -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSOC idea discussion: TurboGears Content Management System
Yea, that was my fault, I got hard-core about the feature freeze only after I first encouraged adding the new feature. In my defense, I wanted that new feature ;) And also in my defense, we needed to respect the feature freeze and get 2.0 out the door so we can start adding features like this to 2.1!. Fortunately, there's a simple update to your quickstart that re-enables support for tgext.pages. You just have to break websetup out into two functions, one which initializes your db, and another which bootstraps your data. --Mark On Mon, Mar 23, 2009 at 10:54 PM, Jorge Vargas jorge.var...@gmail.com wrote: On Mon, Mar 23, 2009 at 3:59 PM, dimazest dimaz...@gmail.com wrote: On Mar 23, 1:18 pm, Florent Aide florent.a...@gmail.com wrote: On Mon, Mar 23, 2009 at 12:35 PM, dimaz...@gmail.com dimaz...@gmail.com wrote: Hello, I'm interested in a TurboGears CMS development for this GSOC. I would suggest you join forces with thishttp://bitbucket.org/jon1012/tgextpages/ which is a light CMS we are working on and which extends any TurboGears application. I tried to setup tgext.pages for a newly created project. I used virtualenv with --no-site-packages, installed TurboGears version 2.0b7. Then I installed tgext.pages by doing python setup.py develop. First, I tried to install pages model to the project by Paster Script (easy), but I got the following message Adding Pages Database Definition to your TG Project === This does not appear to be a TurboGears2 application I ran it from the directory where development.ini, setup.cfg and setup.py are located. right, due to a misundestanding pages paster command depends on a feature that was pushed into 2.1 so the automatic install doesn't works anymore. We are going to have to change the docs for 2.0.x. See the huge thread currently going on about DB Creation Having no luck with script I added required lines to the files, as described in the Manual (harder) section, now I get the ImportError: No module named i18n exception ( full traceback http://paste.turbogears.org/paste/39891 ) How can i get the tg.i18n module? currently pages requires TG2.0rc1 Dima -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Quickstart and DB creation
Well, since this is a template only change, you can make the change after quickstart and never install 2.1 and there are several issues that go into a feature freeze: 1) potential for breaking things 2) need to rewrite docs 3) need for public blog posts, articles, etc to work with the released version And I put them in the order of imporance I think they have. But I do think that making the code in a python magazine article just work is worth the trouble of 2.0 users having to split this apart manually. I know that sucks a little bit for pages, but the bad marketing of having a magazine article go to thousands of people with code that does not work out of the box is worse. And from Gustavo's message I assume that he had people put extra bootstrap data into websetup.py and showed that in the article -- which is what would be broken by chris's change. --Mark On Sun, Mar 22, 2009 at 5:02 PM, Jorge Vargas jorge.var...@gmail.com wrote: On Wed, Mar 18, 2009 at 7:14 AM, Gustavo Narea m...@gustavonarea.net wrote: Hello, If we're supposed to be in a feature-freeze, that's for people to be confident that from now on things aren't going to change, unless a critical bug has to be fixed, so that they can start building software and writing about TG2 with the guarantee that their product isn't going to expire some days later. I think you missed the point either here or of feature freeze. if the API is keep intact (which from talking to precious) I believe it was. then the change can go into the feature freeze and nothing should break. And it is not a big problem. This isn't really a new feature is spliting it in half. And making the old one call the 2 new ones. It's more like refractoring and the first rule of refractoring is that you should not break anything. On the other hand, independent of the article I wrote, I think we must comply with the feature freeze strictly, specially in non-trivial changes like this (splitting a function into three ones, defined in newly-created modules each). again that is not feature freeze it's just code cleanup, this is as harmless as splitting a file in two The more complex a change is, the more chances to introduce a bug. And at this point we shouldn't take the risk of introducing bugs, but just fix the remaining ones. Right I do agree with you on this, but from Chris commit history I think we can all agree he has never broken the trunk. Finally, I think this change has to be moved to the upcoming 2.1 branch (trunk, when there's a 2.0 branch). I love the idea, I think think it's reasonable, but I think it's too late to go in v2.0. Otherwise, this will be bad for PRs. So the final decision on this is to keep it out? because that just threw a snowball on me. In order to get started with the new turbogears.org we need pages 0.1 released which now depends on this, which means we need TG2.1 which is unreleased, which means I need to either break the security policy of the server (installing unreleased software) or install a hacked version of TG2.0rc1 in order to get this going. And as I said above this is all api stable, nothing will break with the FIRST stage of the changes (needed for pages) the second set of changes should be 2.1 only. my 2 cents Cheers, =Gustavo On Tuesday March 17, 2009 19:05:50 Mark Ramm wrote: Works for me. We can try to shoehorn this into rc1 if we can get it done in the next day or so -- otherwise it'll be a 2.1 feature. I want it done now, but making that happen will require updating several docs :/ So, I'm a bit hesitant to about just going for it directly. --Mark Ramm On Tue, Mar 17, 2009 at 1:53 PM, Florent Aide florent.a...@gmail.com wrote: On Tue, Mar 17, 2009 at 4:56 PM, percious ch...@percious.com wrote: I have begun work on our new extensions methodology. (Some call this component architecture). I am working with Jorge and Jon to try and [...] websetup/ __init__.py : contains setup_app which will be a combination of bootstrap and schema setup nice this will definitely make things easier. Florent. -- Gustavo Narea xri://=Gustavo. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSOC idea discussion: Merging object dispatch with Routes 2 middleware.
This would be a great project. I do think it might make sense to work with Routes 1 rather than Routes 2, or to push forward a more limited Routes 2 quickly so that we can integrate with that. Ben Bangert from the Pylons project would be able to help us sort this one out. One quirk in the process would be the lookup methods, which would still require some manner of traditoinal object dispatch once they have been hit, since they dynamically generate objects on which dispatch will happen, and that can't happen once at startup. But I think the solution here would likely be to just create rules for the lookup methods, and them do dispatch as we do now in that one case. --Mark Ramm On Sat, Mar 21, 2009 at 12:06 PM, Hao Lian shadytr...@gmail.com wrote: Hi! I'd be interested in working on the object dispatch + Routes 2 idea for GSOC 2009. I have a few questions: * Routes 2 looks like it's in the early stages of development without much documentation yet [1]. Should my application also include integration with Routes 1? Or perhaps start integration with Routes 1 first and then move it to Routes 2 as part of a later stage? [1]: http://wiki.pylonshq.com/display/routes/Home * Would this be a good implementation strategy?: Pick a time before the application is initialized to walk through the object tree starting at RootController. At each controller, get a list of �...@exposed methods and create Route rules for each of them. And keep repeating downward in the tree until there are no more controllers left. I've only been able to quickly look through the object dispatch code, so this is definitely a rough sketch. And this would happen only once at some pre-specified time rather than call time, as the Ideas page mentions, and should provide a performance boost for large applications. Thanks for any input! Hao Lian, Computer Science at Princeton University. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Quickstart and DB creation
I after a bit more thinking about this, and after seeing the size of the change, I think I'm back to thinking this will be a 2.1 feature. But I know it's nice stuff and nesissary for tgext.pages, but the component stuff is a 2.1 goal, and we do have a feature freeze going on, and I need to be more hardcore about enforcing that. If we can release 2.0 final, and 2.1 a few weeks later, I'm fine with that, but I don't want to delay or break 2.0 ;) So, to hopefully make everybody happy, I say we leave this in trunk and declare trunk the place for 2.1 work, and I'll create a 2.0 branch right away, based on the rev before this change for the rc1 release. What do you think? On Wed, Mar 18, 2009 at 7:14 AM, Gustavo Narea m...@gustavonarea.net wrote: Hello, If we're supposed to be in a feature-freeze, that's for people to be confident that from now on things aren't going to change, unless a critical bug has to be fixed, so that they can start building software and writing about TG2 with the guarantee that their product isn't going to expire some days later. I love to see TG2 evolve, but that this has been applied in the feature-frozen branch I'm using to write a short series of articles using TG2 and that it already out dates the first article (which was delivered)... It really bothers me. If I can't trust that we were serious when we announced that feature freeze, then I'll switch over to a truly stable framework for my next article. On the other hand, independent of the article I wrote, I think we must comply with the feature freeze strictly, specially in non-trivial changes like this (splitting a function into three ones, defined in newly-created modules each). The more complex a change is, the more chances to introduce a bug. And at this point we shouldn't take the risk of introducing bugs, but just fix the remaining ones. Finally, I think this change has to be moved to the upcoming 2.1 branch (trunk, when there's a 2.0 branch). I love the idea, I think think it's reasonable, but I think it's too late to go in v2.0. Otherwise, this will be bad for PRs. Cheers, =Gustavo On Tuesday March 17, 2009 19:05:50 Mark Ramm wrote: Works for me. We can try to shoehorn this into rc1 if we can get it done in the next day or so -- otherwise it'll be a 2.1 feature. I want it done now, but making that happen will require updating several docs :/ So, I'm a bit hesitant to about just going for it directly. --Mark Ramm On Tue, Mar 17, 2009 at 1:53 PM, Florent Aide florent.a...@gmail.com wrote: On Tue, Mar 17, 2009 at 4:56 PM, percious ch...@percious.com wrote: I have begun work on our new extensions methodology. (Some call this component architecture). I am working with Jorge and Jon to try and [...] websetup/ __init__.py : contains setup_app which will be a combination of bootstrap and schema setup nice this will definitely make things easier. Florent. -- Gustavo Narea xri://=Gustavo. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Quickstart and DB creation
I totally understand, and we'll have a branch with this in it right away -- and that branch will be called trunk. ;) I will also branch off the 2.0 docs for polishing, and leave your new docs in trunk. --Mark Ramm On Wed, Mar 18, 2009 at 1:28 PM, percious ch...@percious.com wrote: By the way, we really need HG. I think that should be a goal for pycon. We need to be able to easily branch on stuff like this. Also, i have every confidence that this change will not introduce errors. I will also be online almost continuously over the next few weeks for support (9-9 MDT) cheers. -chris On Mar 18, 11:23 am, percious ch...@percious.com wrote: Well, it's in and the docs are updated. Dunno what to say, you mentioned this after I had already implemented. On Mar 18, 6:17 am, Mark Ramm mark.mchristen...@gmail.com wrote: I after a bit more thinking about this, and after seeing the size of the change, I think I'm back to thinking this will be a 2.1 feature. But I know it's nice stuff and nesissary for tgext.pages, but the component stuff is a 2.1 goal, and we do have a feature freeze going on, and I need to be more hardcore about enforcing that. If we can release 2.0 final, and 2.1 a few weeks later, I'm fine with that, but I don't want to delay or break 2.0 ;) So, to hopefully make everybody happy, I say we leave this in trunk and declare trunk the place for 2.1 work, and I'll create a 2.0 branch right away, based on the rev before this change for the rc1 release. What do you think? On Wed, Mar 18, 2009 at 7:14 AM, Gustavo Narea m...@gustavonarea.net wrote: Hello, If we're supposed to be in a feature-freeze, that's for people to be confident that from now on things aren't going to change, unless a critical bug has to be fixed, so that they can start building software and writing about TG2 with the guarantee that their product isn't going to expire some days later. I love to see TG2 evolve, but that this has been applied in the feature-frozen branch I'm using to write a short series of articles using TG2 and that it already out dates the first article (which was delivered)... It really bothers me. If I can't trust that we were serious when we announced that feature freeze, then I'll switch over to a truly stable framework for my next article. On the other hand, independent of the article I wrote, I think we must comply with the feature freeze strictly, specially in non-trivial changes like this (splitting a function into three ones, defined in newly-created modules each). The more complex a change is, the more chances to introduce a bug. And at this point we shouldn't take the risk of introducing bugs, but just fix the remaining ones. Finally, I think this change has to be moved to the upcoming 2.1 branch (trunk, when there's a 2.0 branch). I love the idea, I think think it's reasonable, but I think it's too late to go in v2.0. Otherwise, this will be bad for PRs. Cheers, =Gustavo On Tuesday March 17, 2009 19:05:50 Mark Ramm wrote: Works for me. We can try to shoehorn this into rc1 if we can get it done in the next day or so -- otherwise it'll be a 2.1 feature. I want it done now, but making that happen will require updating several docs :/ So, I'm a bit hesitant to about just going for it directly. --Mark Ramm On Tue, Mar 17, 2009 at 1:53 PM, Florent Aide florent.a...@gmail.com wrote: On Tue, Mar 17, 2009 at 4:56 PM, percious ch...@percious.com wrote: I have begun work on our new extensions methodology. (Some call this component architecture). I am working with Jorge and Jon to try and [...] websetup/ __init__.py : contains setup_app which will be a combination of bootstrap and schema setup nice this will definitely make things easier. Florent. -- Gustavo Narea xri://=Gustavo. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog:www.compoundthinking.com/blog -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Release Candidate 1 candidate available
Thanks all. There was an issue with __before__ and a small test in the flash messages from authorization failures that had to be updated. We will be incorporating these new changes into the release candidate and releasing soon. :) Sorry about the delay, but I was without internet last night so I wasn't able to work on this stuff. :( --Mark Ramm On Wed, Mar 18, 2009 at 8:55 PM, cd34 mcd...@gmail.com wrote: Brand new virtual env, Debian/Linux/testing worked without issue. Moved two controllers over from some prior testing and both worked. Need to still test secure controller, but, I suspect that should work as it did. On Mar 16, 9:40 pm, Mark Ramm mark.mchristen...@gmail.com wrote: Here's the new index that could become the long awated RC1 -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Change in trunk status
Bugfixes for 2.0 should now go into the 2.0 branch AND trunk. But Trunk has new 2.1 features underway right now. There setup-app functionality has been broken out into two pieces, and work is beginning on the ComponentArchetecture, site-components, tgext plugins, or whatever you want to call it that provides ready to use components for tg2 sites. I have also updated the eggs in the rc1 test site, and have uploaded a new version of the docs. I have to crash for the evening, but I will test this some more and hopefully do the rc1 release tomorrow. Thanks everybody who helped make this happen! -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Quickstart and DB creation
Works for me. We can try to shoehorn this into rc1 if we can get it done in the next day or so -- otherwise it'll be a 2.1 feature. I want it done now, but making that happen will require updating several docs :/ So, I'm a bit hesitant to about just going for it directly. --Mark Ramm On Tue, Mar 17, 2009 at 1:53 PM, Florent Aide florent.a...@gmail.com wrote: On Tue, Mar 17, 2009 at 4:56 PM, percious ch...@percious.com wrote: I have begun work on our new extensions methodology. (Some call this component architecture). I am working with Jorge and Jon to try and [...] websetup/ __init__.py : contains setup_app which will be a combination of bootstrap and schema setup nice this will definitely make things easier. Florent. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Quickstart and DB creation
Also, while I am at it, I am going to add some comments to the quickstart which will work as template hooks for extensions. I'm not sure how many of these hooks we will need, or how we should document them, but this is a work-in-progress. Could you explain a little? Hooks for template extensions, templates for hooks to load extensions, something else? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: What is the purpose of Controller in quickstart at lib/base.py
Fell free, It was added long ago, over my partial objection because someone thought it was an important extension point -- but it does not really do anything and I don't know people actually using it. --Mark Ramm On Mon, Mar 16, 2009 at 4:02 AM, Jorge Vargas jorge.var...@gmail.com wrote: On Thu, Mar 12, 2009 at 8:34 AM, Jorge Vargas jorge.var...@gmail.com wrote: Could someone remind me why we have this? and why it comes from object?? to me it seems like cruft that should be removed. the code fragment is class Controller(object): Base class for a web application's controller. Currently, this provides positional parameters functionality via a standard default method. pass anyone?? I'm going to delete it as it just confuses people... -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Controller composition and quickstart
+1 sounds good, and I think it will make life easier for users who quickstart multiple projects which is nice. --Mark On Mon, Mar 16, 2009 at 4:18 AM, Jorge Vargas jorge.var...@gmail.com wrote: Hi, For some time I have been thinking on which will be the best way to merge two controllers into the same PATH, percious made a suggestion the other day on IRC which IMO is brilliant. it was something along the way of They are classes simply make a subclass of both controllers Ever since we have been using it for tgext.pages, which got me thinking. Why don't we do that with quickstart? well here is the result. The code simply splits the RootController into 3 controllers. AuthenticationController (login,logout, post_login, post_logout), DemoController (about,index,auth,manage_permission_only,editor_use_only) and RootController (admin, error, extends both of the above) IMO this is - way nicer (cleaner) than the original everything smashed together approach - It introduces new and old users, to this great idea of mounting 2 controllers to pull functionality together - it's not magical at all (because you do know that python has multiple inheritance do you?) -it's also great to help non-newbies in getting rid of the newbie oriented part of the quickstart. - it simplifies the quickstart code a lot (removes a bunch of if/elif blocks). In fact I think the AuthenticationController could be moved inside /lib together with BaseController as it's something people aren't going to change a lot. is this going back to the SecureController/Controller stuff? well kind of but not really as we aren't making two separate hierarchies we are making just one. PS: the code hasn't been adapted for no-auth controllers I wanted to see if it was commitable before getting it into full shape. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: RC1 status and ticket triage
Well, good news, bad news. I had no internet access yesterday due to a comcast outage, so I'll be preping the rc1 release tonight (and probably not actually doing the release until late tuesday or early wednesday) so there's time for people to work on things a bit. And it would be good for some folks to test trunk in the meantime since there have been a couple of controller security changes. We're getting very, very close. I want to create a 2.0 branch by this weekend, so that crazy new stuff can happen in trunk at pycon without messing up our 2.0 release path. --Mark On Sun, Mar 15, 2009 at 5:17 AM, Jorge Vargas jorge.var...@gmail.com wrote: On Sun, Mar 15, 2009 at 12:42 AM, Mark Ramm mark.mchristen...@gmail.com wrote: I very much want to finish RC1 this weekend or monday at the latest. There are quite a few tickets in rc1, and I'll triage them all tonight. Any help with any issues would be greatly appreciated! Ok, triaging done. Looks like all our major issues are resolved, I will try to find some time tomorrow away from my taxes and real life work to finish up a couple more issues, and start preparing RC1. Awesome work mark, looking good indeed. Sadly Sunday I can't help unless it's on the night. and monday I can do I just added 2278, which may as well end up in rc2 but It has been on my plate for some time now. All I need to do is sit down and write it. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSOC
Well, we have not yet been accepted as a mentoring organization, but we did upload an application template to the GSoC app, so it should be there if/when we get accpeted. I think the first thing to do is start thinking about, and perhaps asking questions on this list about how you might go about working on one of these projects. We will be taking people's activity talking about these things on this list pre-GSoC student selection into account as we choose students. So, thanks for opening up this discussion! --Mark Ramm On Mon, Mar 16, 2009 at 3:56 PM, dimazest dimaz...@gmail.com wrote: Hello all, I'm a student looking for a project for the GSOC 2009 and I would like to participate in TurboGears development. Thank you for the detailed project descriptions. I have been tracked TurboGears for several years, even bought the book about it and played around. I played with tg creating some small projects, one of them even worked. I know SQLAlchemy. I'm interested in following projects: * TurboGears Content Management System. * Auto Buildbot,auto interface, auto document generation. * Design turbogears apps online without command line. Total web design toolkit for tg2. What should I do next? How should my application look like? All the best, Dmitrijs Milajevs On Mar 12, 7:24 pm, Lukasz Szybalski szybal...@gmail.com wrote: On Thu, Mar 12, 2009 at 2:40 AM, Jorge Vargas jorge.var...@gmail.com wrote: On Tue, Mar 10, 2009 at 10:09 AM, Florent Aide florent.a...@gmail.com wrote: On Tue, Mar 10, 2009 at 2:46 PM, Mark Ramm mark.mchristen...@gmail.com wrote: http://docs.turbogears.org/GSoC/Ideas2009 I added an idea and a bare minimum formatting in rst for the page. Florent. I'll be willing to mentor someone this year. I have been cooking a mercurial frontend project which I'll post with more details later. What is exactly needed for the administrator position? I may be able to fill that in, although I prefer to be the last candidate as I'm already into way too many things. I would like to see 2 projects: 1. Continuation of a buildbot. Give it some kind of interface and connect autosetup, auto install , auto epydoc generation to tg and its requirements and those software requirements. I would like to have every single package that is pulled for tg to have its own epydoc for each version that was generated; all on one page. 2. Design turbogears apps online. Similar to web2py. It is an interface for running and changing apps online. Right now the turbogears is installed, generated and modified via command line. This web interface would run commands like paster quickstart paster setup-app and paster serv. After that a user would start modifying the root.py, model.py, etc via a web interface. This would allow web designers to go straight to designing the apps instead of command line. Web interface: - create new tg app - setup database - start project - browse the files - modify root.py Thanks, Lucas -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Release Candidate 1 candidate available
Here's the new index that could become the long awated RC1 http://turbogears.org/2.0/downloads/2.0rc1/index/ If you're interested in testing it out, easy_install tg.devtools with the above index, quickstart a new project, do setup.py develop (and if you used auth paster setup-app development.ini) start it up and let me know if everything works. Try it with your TG2 applications, let me know if those work, and otherwise kick the tires a bit. If it works for people I'll point 2.0/downloads/current/index/ at it and we will be off to the races. ;) -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Fwd: [turbogears-commits] r6503 - in trunk/tg: . test_stack
==
--- trunk/tg/test_stack/test_authz.py (original)
+++ trunk/tg/test_stack/test_authz.py Sat Mar 14 18:29:34 2009
@@ -155,7 +155,7 @@
class ControllerWithAllowOnlyDecoratorAndAuthzDenialHandler(TGController):
Mock TG2 protected controller using the @allow_only decorator, but also
-using .failed_authorization()
+using ._failed_authorization()
@@ -311,7 +311,7 @@
self._check_flash(resp, 'The current user must have been
authenticated')
# As an authenticated user:
environ = {'REMOTE_USER': 'someone'}
-resp = self.app.get('/hr/', status=403)
+resp = self.app.get('/hr/', extra_environ = environ, status=403)
assert you can manage Human Resources not in resp.body
self._check_flash(resp, r'The current user must be
\hiring-manager\')
@@ -328,7 +328,7 @@
self._check_flash(resp, 'The current user must have been
authenticated')
# As an authenticated user:
environ = {'REMOTE_USER': 'someone'}
-resp = self.app.get('/hr/hire/gustavo', status=403)
+resp = self.app.get('/hr/hire/gustavo', extra_environ = environ,
status=403)
assert was just hired not in resp.body
self._check_flash(resp, r'The current user must be
\hiring-manager\')
@@ -387,6 +387,7 @@
def test_authz_granted_without_require(self):
environ = {'REMOTE_USER': 'hiring-manager'}
resp = self.app.get('/', extra_environ=environ, status=200)
+print resp
self.assertEqual(you can manage Human Resources, resp.body)
def test_authz_denied_without_require(self):
@@ -396,7 +397,7 @@
self._check_flash(resp, 'The current user must have been
authenticated')
# As an authenticated user:
environ = {'REMOTE_USER': 'someone'}
-resp = self.app.get('/', status=403)
+resp = self.app.get('/', extra_environ = environ, status=403)
assert you can manage Human Resources not in resp.body
self._check_flash(resp, r'The current user must be
\hiring-manager\')
@@ -410,10 +411,11 @@
# As an anonymous user:
resp = self.app.get('/hire/gustavo', status=401)
assert was just hired not in resp.body
+print resp.body
self._check_flash(resp, 'The current user must have been
authenticated')
# As an authenticated user:
environ = {'REMOTE_USER': 'someone'}
-resp = self.app.get('/hire/gustavo', status=403)
+resp = self.app.get('/hire/gustavo', extra_environ = environ,
status=403)
assert was just hired not in resp.body
self._check_flash(resp, r'The current user must be
\hiring-manager\')
@@ -452,7 +454,7 @@
# As an anonymous user:
resp = self.app.get('/mounted_app/da-path', status=401)
assert Hello from /mounted_app/ not in resp.body
-self._check_flash(resp, r'The current user must be \gustavo\')
+self._check_flash(resp, r'The current user must have been
authenticated')
# As an authenticated user:
environ = {'REMOTE_USER': 'non-gustavo'}
resp = self.app.get('/mounted_app/da-path', extra_environ=environ,
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: RC1 status and ticket triage
I very much want to finish RC1 this weekend or monday at the latest. There are quite a few tickets in rc1, and I'll triage them all tonight. Any help with any issues would be greatly appreciated! Ok, triaging done. Looks like all our major issues are resolved, I will try to find some time tomorrow away from my taxes and real life work to finish up a couple more issues, and start preparing RC1. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
Re: is TG2 really not wsgiorg_args compliant? and if it isn't should it care? Was: [tg-trunk] tgext.crud and repoze.what integration I believe we can do better
Could you explain why TG2 isn't compliant? and why is it a serious bug ? Because it manipulates the named and positional arguments, but doesn't define them in the relevant variable in the environ. SNIP If you want interoperability, then you should follow standards. So this time, if you want the parameters extracted from TG2's object dispatch stuff to be usable in TG-independent stuff, then they must be made available in a TG- independent way -- and there's already an standard for that. Well, TurboGears Root controller is a WSGI app, but tg controller methods are NOT wsgi apps, so I don't think that technically we are doing anything wrong, as we're not officially doing wsgi app dispatch, but choosing methods --within-- a wsgi app and calling them with a totally different signature than the wsgi spec. But, I do think it's a good idea to follow the spec, and it should be pretty easy to make it do that -- this would be a great item for the pycon sprint if we don't get to it before then. --Mark Ramm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Beta 7 -- Critical security update for b5 and b6 users!
TurboGears beta 7 is a important security update for Beta 5 and Beta 6 users. Please update all production apps form b5 or b6 to beta 7 immediately. We're doing a Beta 7 rather than an RC1 because of the importance of this issue, and our desire to make absolutely sure that we've solidified all of this before doing a release candidate. Fortunately the upgrade from b6 should have no backwards incompatible changes, and should require no changes to your project B5 users should update to b6 and then b7. B6 users should be able to do a simple easy_install -U as described in the install instructions: (tg2env)$ easy_install -U -i http://www.turbogears.org/2.0/downloads/current/index tg.devtools (instructions:http://turbogears.org/2.0/docs/main/DownloadInstall.html ) The check for controller wide security was not working properly, and we discovered that not enforcing controller level security restrictions on subcontrollers.We take this very seriously even though it happened in a beta, and we are taking steps to assure that it won't happen again. It turns out that we moved some tests that would have prevented this into another package, and that left one small thing in TG which was no longer tested, and of course that's where our problem was. We've added several tests to make sure this can't happen again, and I've changed the way that we check controller authorization to be less fragile. In order to make sure that the rapid development of our security stuff has not created any other issues, and in order to review all existing authorization/authentication code we'll be holding a security sprint this weekend. We will be adding additional integration tests, and doing a full audit of all security related packages on Sunday. There was also another issue that kept the __before__ method used by our controller security system from running properly. Special thanks goes out to Alberto Valverde for contributing to fixes to both these critical issues. We've also added some more tests to the quickstart. In particular there are tests for the security system built right into the quickstarted project so users can easily see how to assure that their security measures are working the way they expect, and we have some additional helpers for testing authorization rules coming in the next release. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Pylons objects in TG2
Well, we're not exporting any of the on letter variables, and I don't like 1 letter variables generally. But I'll not fight about it if there's concensus that we should export them. On Tue, Mar 3, 2009 at 10:02 AM, Christoph Zwerschke c...@online.de wrote: In tg.__init__, - tmpl_context is exported, but not c - g is defined, but app_globals is exported - neither h nor webhelpers are defined or exported My opinion is that both one-letter and full names should be exported by tg, but at least we should be consistent. -- Christoph -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Pylons objects in TG2
Looks like pylons is helping to make the decision for us: http://pylonshq.com/project/pylonshq/changeset/2058%3A45f1838d28a5 c and g are going away in the next version of Pylons, so we should be forward compatible ;) On Tue, Mar 3, 2009 at 8:16 PM, Chris Miles miles.ch...@gmail.com wrote: On 04/03/2009, at 6:06 AM, Christoph Zwerschke wrote: Mark Ramm schrieb: Well, we're not exporting any of the on letter variables, and I don't like 1 letter variables generally. But I'll not fight about it if there's concensus that we should export them. We need to do something anyway: It makes no sense that tg.__init__ imports g from pylons and puts an undefined app_globals in __all__. Currently you can from tg import g, but not from tg import app_globals. On the other hand you can from tg import tmpl_context but you can't from tg import h. We must decide to either promote all the one-letter names or all the longer names - or both variants. My preference would be to export only the full names and let the user alias them to one letter names if that's what they prefer (which may become common practice, but isn't forced), from tg import app_globals as g from tg import tmpl_context as c Cheers, Chris Miles -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 quickstart command
This is fine with me, though we are in feature freeze and I'm a bit hesitant about introducing changes at this point. But I trust you, and it does make sense. --Mark On Mon, Mar 2, 2009 at 10:13 AM, Christoph Zwerschke c...@online.de wrote: Currently, the -a option of paster quickstart expects another yes or no argument. I think that's a bit un-intuitive and different to the behavior of the -i option in TG1 and the other boolean option in TG2 such as -g. I'd like to change this so that -a adds authorization, and ask the user if -a is not provided. We can also add another -q option that would skip all questions to the user and use the default values. -- Christoph -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
