Very reflective of a large, but quiet developer community
I'd say this is a cultural problem, but not an insurmountable one. One aspect of Rails is that it excites people. Excitement has a lot to do with interpretation. Getting your job done well and on time is not exciting. But it could be exciting, if you phrase it differently; and that's what Rails has done. Sharing can be exciting, and experimentation and playfulness. Important things to think about.
So with Python Paste and other such systems, are we aiming to convert Zope developers/programmers to unite around a different web framework?
No, I don't think it makes sense to focus on converting current Python web programmers. Paste isn't intended to convert anyone to a particular framework, as it isn't a framework and is intended to encompass several frameworks. Potentially any framework. Once Zope goes WSGI (which is in the works) it could run Zope too (though I suspect it won't attract that crowd as much, as they already have their own custom infrastructure to match Paste). I want to make the experience better for people who aren't doing Python web programming; both web programmers who aren't using Python, and Python programmers who aren't using the web.
When you say "get our shit in order" what do you mean?
Being able to answer the question "so how do I do web programming in Python" easily. Being able to provide robust infrastructure. Being able to write documentation that is both complete and concise (which simply isn't possible if the underlying code doesn't allow for that). All the boring stupid stuff that needs to be done to make working apps, but isn't exciting.
Ok, I'm not sure how Paste will meet any of the goals you seem to desire. (This is assuming I'm understanding Paste correctly, as the comments on your blog have demonstrated its exceptionally difficult to explain Paste to other web developers, so how one could explain it to a new person....)
First, you want Paste to encompass other frameworks, however I'm not sure how thats possible. From several of the frameworks I've looked at, they work in such a different environment that I don't see how they can be modified to fit into Paste without destroying what makes them unique and valuable to their creators.
As one example, when I was reading over Paste, it seems to have its own Resolver in it, that then dispatches to Webware or a different framework. Myghty has a very powerful resolver methodology that we wouldn't want interrupted or pre-empted. I'm sure many other frameworks have a lot of parts to them that their developer doesn't want stepped on by some sort of "universal" meta-framework.
Being able to answer the question "so how do I do web programming in Python" easily
If we take Paste to what I see as your desired conclusion, ie, you download Paste, hit a command, and have an app ready to go with the framework of your choice (assuming there's a half dozen or two frameworks ppl have integrated). How does that make it easy? Sure, installing it was easy, but now what? How do you choose what framework to set your app to? How does that help documentation? There's still a dozen different frameworks, written by a dozen or more different people, documented by a dozen or more people, etc.
How easy would Rails be if once you had it installed, you had to choose from a dozen different framework paradigms?
As I'm working actively with Myghty and web development, I'd love to see it included in Paste. But why spend time developing that out if its easier and quicker to do what Paste provides myself?
For example, I'm currently writing up a little script, that when run lays out a basic directory template with some defaults setup for Myghty. It's fairly simple, and the directories it lays out are pretty conventional for a MVC webapp. With a single command, I can run the Myghty app standalone and play with it locally, however it also has a CGI, WSGI, and mod_python set of scripts allowing it to easily be used in any of those environments with no modification.
The module component I'm writing for use with this layout will be flexible enough to call methods (actions from the Rails-jargon world) based on URL if desired, or any other scheme. Myghty has a Path Translate function that works as an internal redirect of sorts, sort of like Rail's routing mechanism, I have Module Components? to handle mapping to controllers, and the Myghty template language to handle the view.
In the earlier Ruby post, some of the responses were wondering how Myghty is a framework vs template language, maybe that helps some?
Anyways, with one simple command, a small set of directories will be laid out, ready to run, with an easy to configure set of mapping rules to controllers and methods. It will also deal with a bunch of your complaints about Ruby's implicitness by relying more on Python's explicit nature (ie, you pass the arguments to templates rather than having them all copied, the URL can map to components and methods in whatever method desired, things aren't passed-by-name everywhere).
Add a dozen different frameworks, and its Paste, no?
Just wanted to clarify my prior comment as it might come off "flame-ish". My main intention was not to insult Paste or claim Myghty was the way. It was focused merely on realistic goals given the developers working on various projects.
As far as I know, Ian is the sole person working on SQLObject and FormEncode. I really really dig SQLObject and use it extensively, and I'm starting to use what I can from FormEncode to as its a really killer way to verify/coerce forms. Paste is yet another project that Ian's tackling. How many projects can you work on at once before some of them start lapsing?
The goal of my prior comment was, is Paste the solution? Will being able to easily install a dozen or two frameworks help a new web developer? How will the documentation be collected in one location and made uniform? Will Paste come with bundled frameworks, or will the framework maintainer be able to push framework updates down independently of Paste?
I'm sorry about the tone my other comment.
That's it. I'll shut up now. :)
As far as I know, Ian is the sole person working on SQLObject and FormEncode.
Actually, I've been lapsing on SQLObject work, but thankfully Oleg has been doing a good job maintaining it, and there's a group of people answering questions about it and submitting patches. So it's working out fine. There's been other significant contributions to FormEncode, and I'm hoping by keeping its scope very limited and clearly defined that it will also be able to exist on its own at some point, maybe even reach "maturity". And while Paste represents a particular vision of mine, I hope to bring other developers and visions into it; I know it's not easy getting an open source project to the point where it really is a collaborative project, but it's possible and something I think about quite a bit as I develop these things.
Paste is still a work in process, so its advantages aren't extreme. You can reimplement its functionality for your framework, and it wouldn't be that hard. It's also quite easy to use Paste with your framework, so I honestly don't know that it's easier to do things on your own, even if you factor in the getting-to-know-you time (at least if you are planning to support WSGI at all). Peter Hunt said it took him about 4 hours to convert Subway to Paste; I haven't seen the details of his code yet, but I think that includes some degree of integrating setup scripts and other pieces.As one example, when I was reading over Paste, it seems to have its own Resolver in it, that then dispatches to Webware or a different framework.
It is definitely not expected that all frameworks will share a resolver. paste.urlparser does file-based parsing as WSGI middleware, but you could implement other strategies as middleware, or just provide a single entry point and do it internally. That's how initial Quixote support will work -- it'll use their Publisher without modification, and maybe in the future that can become middleware. I think it's reasonable to expect framework support to start as a monolithic integration -- a single entry point and everything after is internal to the framework. Later pieces can be factored out, or replaced with existing Paste functionality. This is the way that WSGI middleware can make a framework melt away. But it's incremental, and I'm as dedicated to backward compatibility as you probably are, so the buy-in required is gentle.If we take Paste to what I see as your desired conclusion, ie, you download Paste, hit a command, and have an app ready to go with the framework of your choice (assuming there's a half dozen or two frameworks ppl have integrated). How does that make it easy?
That sounds easy to me. Really, I tried the framework comparison thing, and it was really hard because of installation. Not because I couldn't figure out the difference between the frameworks quickly. It doesn't mean there's no work to do for the framework authors, but they can focus on making their frameworks compelling instead of robust or easy to install.How easy would Rails be if once you had it installed, you had to choose from a dozen different framework paradigms?
Paste isn't Rails, at all. There's a couple ideas I'm taking, but only a couple. Like maybe two. They have very different scopes and purposes.[description of new Myghty features...] Add a dozen different frameworks, and its Paste, no?
Paste without the reuse, sharing, or community. I think that's a big difference.