Mike Orr wrote: > On Tue, Jan 6, 2009 at 6:26 AM, vArDo <mateusz.bilin...@gmail.com> wrote: >> I'd like to know what are priorities for these projects. Are example >> apps (blog, cms) important or maybe CRUD is the most-wanted >> subproject? >> > >> [3] http://wiki.pylonshq.com/display/pylonsprojects/Home > > I deleted two of the WebHelpers-related projects that are already done. > > Ben could use some help finishing the Pylons documentation for 0.9.7, > although that's too short a timeframe for the Summer of Code.
Maybe a fun/useful project would be working on a system to make the documentation more useful or browsable? E.g., a comment system or a system to suggest patches. Maybe even with some workflow...? Maybe that scope is too large, and the problem too subtle. Though actually there's several clear models for this (e.g., Django docs) so that would provide a good guide. Writing a series of recipes (that can be tested automatically, probably with buildbot) might be a good addition? Figuring out how to write testable recipes is tricky, but a doable tricky. > Pylons' dependencies need to be ported to Python 3 so that Pylons can be > ported. This requires a lot of deep diving into code. I think it'd work if the main maintainer of the dependency is ready and eager to port to Python 3. Personally I'm stuck on what WSGI should be in Python 3. I think the current definition of WSGI in Python 3 is bullocks. > As for wiki/blog/CMS-related projects and CRUD projects, there have > been several started over the past year that haven't made it onto the > project pages. I don't know what exactly they are or what state > they're in, so you'll have to ask here (and hopefully update the > project pages :). > === > Wiki/blog/CMS > > - Plone can supposedly be embedded in a Pylons app and vice-versa, and > I hear most of Plone has now been ported to Zope 3 (so is cleaner > code). Maybe better integration or documentation would help, possibly > via Repoze.*. Plone is very Zope 2. Repoze has created a WSGI frontend to Plone, and Plone 4 will be WSGI by default, but with a giant Zope 2 thing behind the WSGI. Anyway, not much to be done from the Pylons side. > - Three Pylons CMS projects were started but last time i looked they > were variously abandoned, undocumented, or didn't really seem like > CMS's. Creating new projects that are going to be maintained long-term isn't a good fit for GSoC. > - The Pylons Book has, or had, code for a basic CMS. I haven't read > the final version of the book so I'm not sure if it made it, but James > has the code. > > - Some sites need specifically wiki features, a la MoinMoin. I've > heard MoinMoin is difficult to set up in a WSGI environment and > integrate into a larger site, so perhaps there's something there to > work on. It's a kind of arcane wiki, very attached to the filesystem and without a lot of higher-level abstractions. I don't think it's a good fit. > - There has long been a desire for a Pylons-powered wiki to replace > Confluence as Python's wiki, but MoinMoin was missing some features > and is considered difficult to embed in WSGI applications, and the > Pylons developers didn't want to distract themselves from > documentation writing and framework building. Maybe that could be > started. We'd have to start by making a list of requirements. > > - Some sites need a ticketing system a la Trac or Roundup or > [something new this year?], so there's another integration potential. Related to some of the software management (trac, etc) tasks, there's ClueMapper, which is kind of a WSGI integration project: http://projects.serverzen.com/pm/p/cluemapper (actually integrates Trac). As an integration project it's kind of in lines with Pylons' philosophy, I think, even though most (all?) pieces aren't in Pylons. Filling out that stack with some Pylons apps might fit? I'm not sure it's a good fit as a Pylons project, though, nor is recreating existing open source systems (like Trac) particularly useful. > === > CRUD > > - TurboGears is building something along those lines. Too much going on here to inject someone new, I think. > - FormAlchemy is doing something cruddish (cruddy). I almost > considered integrating it with WebHelpers and @validate, except it's > incompatible with non-SQL databases. > > === > Non-relational databases. > > This is more of a documentation issue than a technical issue. > Non-relational databases like CouchDB, Hypertable, and App Engine's > Datastore provide some unique opportunities compared to SQLAlchemy, > but also provide some unique disadvantages that have to be worked > around or done another way. There are also products that attempt to > reconcile the two database systems or provide a common front end > bridging SQL and non-SQL databases. These are not often used in > Pylons programs because they are so new and unknown. In some cases > that may be because a SQL database *is* adequate and better for the > job, but in other cases it's because people don't understand the > alternatives. So some howtos and pattern code for these products > would be helpful, as well as comparisions between them and SQL and > object databases (ZODB, Durus) for various tasks. > > === > Authentication/authorization > > This has been is another hot issue. Here there are multiple complete > libraries (AuthKit and Repoze.who). It has been suggested that one of > them be blessed as Pylons standard, but we have never made a > comprehensive assessment of what Pylons needs in a standard auth > system (should be somewhat minimalist yet flexible, a la > FormEncode/WebHelpers) and how the two meet it, or whether repoze.who > has too many Zopish dependencies. Some TurboGears developers are also > creating Repoze.what as their standard authorization system, and > perhaps it could be adopted by Pylons at some point. So either work > on Repoze.what itself or on documenting it for Pylons would be > helpful. Seems too ambiguous. > === > ToscaWidgets > > ToscaWidgets is still pretty undocumented for Pylons. Last time I > checked, Alberto's tutorial was the only one up to date but it only > covered simple usage, not building custom widgets. That's the main > reason it's not used much in Pylons applications. it sounded like TW > was making some good advances, dropping C dependencies and that rule > library, and adding Mako templates so that Genshi wasn't required. > That should all have made it more Pylons compatible by now. It's mostly up to Alberto if he'd take on a student, I think. I think there are other classes of things a student could do that aren't in this list, though I can't *quite* think of them at the moment. For instance, creating new Pylons templates that quickstart other kinds of projects (e.g., set up the code infrastructure for a more styled site, one that integrates a lot of components, etc). Potentially an extraction and reworking of paster create (there's Zope people who'd be interested in this too, as they've been using paster create templates quite a bit). Or creating a user management system based on repoze.who, repoze.what, and a SQLAlchemy backend. -- Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@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 -~----------~----~----~----~------~----~------~--~---
