On Tue, Nov 23, 2010 at 9:33 PM, Chris McDonough <chr...@plope.com> wrote: > On Wed, 2010-11-24 at 00:30 -0500, Chris McDonough wrote: >> On Tue, 2010-11-23 at 21:24 -0800, Mike Orr wrote: >> > By the way, with the extensive reorganization of application templates >> > proposed including restructuring the SQLAlchemy support, it puts me >> > and Eric pretty much on hold for writing tutorials and demos, which I >> > was planning to work on over the next five days. (Because I'm snowed >> > in in Seattle plus the Thanksgiving holiday.) >> > >> > So it would be nice if we could decide the API quickly and get a draft >> > implementation of 'pyramid' and 'pyramid_sqla' out, and then worry >> > about getting the manual and tests caught up. That way we can do our >> > work while the latter is being done. >> >> Maybe you could write pyramid_sqla? I have no desire to keep imposing >> my own will on this set of choices, but whatever gets created needs a >> champion and maintainer. >> >> There's no "API" that I know of, unless you mean something in the >> pyramid_sqla package itself. But you can invent it rather than waiting >> for it to be invented.
I can't read Ben's mind. I need to know what he expects it to contain. If we're just talking a Session and Base object and initialize_sql(), that's almost too little to justify a package. Likewise, I can make a 'pyramid' template, but I'd rather have you and Ben and me agree whether it's modules or packages, whether it will include a starter view and welcome-page template, and what the template language should be. These are central decisions that Pyramid as a whole is committing to; we have to make sure all the main developers are comfortable with the decision. Otherwise (A) developers will be unhappy, or (B) we may end up reversing the decision and that has cascading impacts on the docs/tutorials/tests as you've said. I don't mind maintaining templates, but I'm less enthusiastic about writing the associated tests and updates to the manual that you mandate for core contributions. That's why I prefer to make my stuff outside the core for now. Plus I'm still a bit scared of git; e.g., when to create branches because it seems more branch-oriented than Mercurial, and I don't want to end up creating branches for myself that are effectively clutter to other people. >> BTW, I see no chance of coming up with a frozen-in-time paster template >> spec that is static and unchanging. I've been changing docs based on >> required changes to paster templates for years. Changes happen, but Ben usually comes up with excellent structures that fit a lot of use cases and don't need much changing later. He just takes a while to explain enough of his ideas to make spec from. -- Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
