On Wed, Dec 30, 2009 at 1:26 AM, [email protected] <[email protected]> wrote: > So does this mean that Marco is entirely different framework and no > relation with Pylons? I had impression that Pylons 2.0 shall be called > as meta framework.
The Marco core is a meta-framework, akin to Paste. It will have several framework personalities on top of it, including a Pylons-ish one, a TG2-ish one, and a repoze.BFG-ish one. How it will be branded will be decided later. So the "Marco" package in PyPI may end up refering to all of the above, or just to the common core. But either way it will be possible to install the full kit with several framework personalities, or just the parts you're interested in. The Pylons-ish framework can currently run some Pylons applications, so I've heard. If it succeeds it will likely become "Pylons 2". Pylons is like an onion, so it can be difficult to answer, "What is Pylons, and how many changes can you make before it's not Pylons anymore?" In one sense, Pylons is the package called 'pylons'. But a Pylons application includes more, and is held together via Paste. But from a user's perspective, what matters is whether you can run existing Pylons applications unchanged, and whether there are syntax changes. The goal of a Pylons-ish personality is to run Pylons 1 applications (and hopefully 0.9.7 applications) with no changes to the controller code, routing, templates, special globals, 'config' object, or INI file. There may be a front-end configuration step: you may launch it via something other than "paster serve development.ini", or the INI file may be replaced by something equivalent. I envision one personality for existing Pylons applications, and another that would be free to make some syntax changes, such as perhaps replacing the special globals with controller-instance attributes. The latter might be called "Pylons 2", while the former would just be "the Marco port of Pylons". It just depends on what marketing/branding we want to do when the time comes. The code will be the same no matter what the branding is, and maintained by Pylons/TG developers as it is now. > Do we have any document or discussion to understand where the Pylons > lacks and how Marco solves the problem? I tried to explain it in the Roadmap (http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0). Graham's webpages record the raw discussion. The main point is, it's more of interest to framework developers than framework users. Marco is an extension of what Pylons is already doing. Pylons is "the modular framework built on Paste/WSGI". Marco makes it even more modular. Currently you can plug in any server and an application in the INI file, any middleware in middleware.py, and any template engine by reimplementing render_mako(). Marco allows framework developers to plug in reusable framework components in a similar way. You can "build your own framework" by plugging in the dispatch/routing style, request/response style, etc, that you prefer. The name for this is componentization. Zope.component provides the underlying architecture. A configuration file specifies which components to plug in to make a framework. Pylons users wouldn't worry about this: it's all handled in the Pylons-ish personality. But a future user could, if he wanted to, specify the equivalent of a Pylons application (with components, routing, and configuration), all in a single configuration file. It may be in XML, YAML, Python, or another format -- Marco accepts multiple configuration formats. Basically, in 2005 we tried to make framework code more interoperable with WSGI and Paste. That worked well but has some limitations. WSGI was originally envisioned to connect an aribitrary application to an arbitrary server. It happened to allow middleware, and this gave increased pluggability. But five years' experience has shown that raw WSGI is too clunky for many things, even if it still does its original job well. WebOb provides an abstraction above WSGI. And now Marco provides a way to componentize all parts of the framework beyond what middleware/Paste INI can do. We found a component architecture already existing in Zope, extracted from the rest of Zope in Repoze, and decided it was better than building our own. (Because it works and has been tested for ten years.) So that is what has led to this point. The public discussion in Graham's archive goes from January to July 2009. After that, ChrisM and Ben were collaborating privately on their own prototypes, and the discussions weren't archived. I haven't been involved directly since April due to other commitments. But we (the Pylons/TG/BFG developers) are all interested in seeing what comes out of the prototypes, and hope to get more involved in it as we finish our other commitments (Pylons 1.0, documentation, etc). -- Mike Orr <[email protected]> -- 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.
