On Sun, 2010-12-05 at 14:13 -0500, Chris McDonough wrote: > On Sun, 2010-12-05 at 11:00 -0800, Mike Orr wrote: > > On Fri, Dec 3, 2010 at 11:43 AM, Felipe De Siqueira > > <[email protected]> wrote: > > > On Fri, Dec 3, 2010 at 2:41 PM, Chris McDonough <[email protected]> wrote: > > >> > > >> Hi folks, > > >> > > >> Ben Bangert and I recorded an inaugural Pylons podcast yesterday dealing > > >> with Pyramid and the Pylons Project that you might find entertaining. > > >> > > >> The index of Pylons Podcasts is at http://docs.pylonshq.com/#podcasts > > >> > > >> The podcast feed URL (works for me in Rhythmbox, probably will work in > > >> iTunes): http://static.repoze.org/casts/pylons.xml > > >> > > >> Episode #1 can be listened to directly via > > >> http://static.repoze.org/casts/pylonspodcast-1-2010-12-03.mp3 > > > > > > > > > Thank you for the early christmas! > > > > Yes, it was great, and also went into detail on things people were > > curious about (or would have been curious if they'd thought about it), > > such as what you guys are working on right now. > > > > I am working on a pyramid_sqla application template with some other > > Pylons goodies too, so after hearing the podcast I'm thinking it would > > more properly be called pyramid_pylons. > > Could be. > > > Which makes me wonder if there > > should be a pyramid_pylons package containing all these tiny modules > > Ben has been talking about, pyramid_pylons.sqla, > > pyramid_pylons.beaker, pyramid_pylons.paginage, > > pyramid_pylons.routehelper, etc, If they're all independent (i.e., > > don't depend on each other), it may make sense to collect them all in > > one package than to have several teeny-tiny packages. > > I think the packaging of each of those things is dependent on: > > - Will it have a "life of its own", meaning does it make sense for it to > have its own documentation and release cycle? > > - Is it useful outside of a greater whole? For instance, using beaker > outside of a pylons context is useful (I've used it), I can imagine a > paginate thing being useful outside of a Pylons context. I don't really > want to get SQLAlchemy to just get these things.
I should clarify this: there's no reason that pyramid_pylons (or whatever we name it) can't have useful code in it; it needn't be "just a paster template". So I'd say that, yes, if there's no existing or planned package that matches the functionality of what you'd like to add to it, that code should probably go into "pyramid_pylons". If later it seems useful outside of that module, we can create another package. I must say I don't like the name "pyramid_pylons", if only because it's going to be a bitch to explain to people. But I don't have a better idea. - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
