Pylons and repoze.bfg are combined into a Pyramid project.

The information has come up thanks to a booming discussion in the official project group . Specifically, it became known that:

• The Pylons web framework, which recently reached release 1.0, is now in its current form of development. Despite the fact that the full support of the 1.x branch will be implemented for a few more years, no architectural changes or innovations will be made to the project;
• The name “Pylons” should now be associated with the umbrella brand “project“ Pylons ” , which will cover the development of all the technologies that wished to join the community (in a similar way there is a development of projects under the umbrella “ Pocoo ” , among which we can separately mention the WSGI stack Werkzeug , Jinja template engine 2 and documentation system for python projects Sphinx );
• The main technology of the Pylons project today is the Pyramid web framework, distributed under a license derived from BSD .

With this message I would like to notify all developers using or planning to use Pylons in their projects about the current situation around this web framework. Official announcements from the maintainers have not yet arrived, but it is worth expecting in the near future.
It is highly recommended to revise your plans for using Pylons-1.x.
From the point of view of new projects, it is obviously worth joining Pyramid right now, or to choose any other alternative technology - the same Werkzeug, Django and other non-derivative Pylons frameworks.
For those who are already working on Pylons at the moment, there are not so many options for further actions:

• stay on the 1.x branch and calmly manage your projects as long as the framework functionality allows.
  Still, in its current state, Pylons is very stable, minimalist (consists of just over 2000 (two thousand) lines of code), and all interchangeable third-party modules continue to evolve. If necessary, to develop the framework to its increased needs will not be difficult;
• try to transfer your project to the new rails ( well ... yes, if courage and motivation allow, then you can immediately on RoR ), while it has not yet grown in scale and is not stuck tightly to the frozen platform.

For those who, in principle, are interested in the second option, the following is a very succinct retelling of what we have learned from the first acquaintance with the official documentation for the new project .

About the essence of the pyramids

Pyramid grew out of the BFG web framework (also known as repoze.bfg), which in turn is a descendant of the Zope platform, but was developed under the strong impression of Django and Pylons. This year, the developers of BFG and Pylons decided to combine their efforts and the existing developments in the framework of both projects, resulting in a new framework (entertaining, but in the existing documentation the past tense is used - “Until the end of 2010, Pyramid ; it was merged into the Pylons project at the end of 2010 ” ). As the key characteristics of the project, which received maximum attention, the developers note:

• low threshold of entry;
• minimalism;
• speed (performance);
• the most complete and up-to-date documentation (the developers note that due to the small code base they are perfectly able to keep the documentation up to date and in full);
• reliability (each release has 100% code coverage by unit tests);
• openness

By architecture, Pyramid is somewhere in the middle between Django / Pylons / any other WSGI toolkit and the Zope platform, with the result that the developer has the freedom to choose in approaches to customizing some of the components of the system:

• It supports the declarative style of setting up web applications through Zope configuration files (ZCML, XML-based format) ...
• ... at the same time, the framework allows using the purely imperative approach of Pylons with its INI-configs (creating objects manually, setting them up in accordance with the parameters of the INI-config and then calling the methods of these objects in the right places);
• traversal-algorithm is supported for searching and calling the request handler (descent "from the root object - to - nested" in the column of model-objects in strict accordance with the hierarchy reflected in the requested URL). A similar approach is also used in the CherryPy framework ...
• ... at the same time, it is allowed to use the standard URL routing method for the pattern (URL Dispatch), as done in Pylons and Django, as well as the tolerance and m mixed approach from the traversal algorithm and pattern routing;
• Pyramid uses the MVC architectural pattern, but in a slightly modified form. Thus, the components “View” and “Controller” are combined into one “View” entity, which is responsible for presenting the data stored in the “Model”, but has two different contexts - “View Callable” and “View Handler”.
• View Callable is a callable object (a function, or a class with a specific __call__ method) that is responsible for processing the incoming request. Its closest analogue in the Pylons application is the action method inside the controller class. Accordingly, the controller class itself is the closest analogue to what is called the View Handler in Pyramid;
• Like Pylons, the framework does not impose on the developer any specific technologies for storing and managing data.

Pyramid's own codebase consists of approximately 5000 (five thousand) lines of code, against a little more than 2000 lines in Pylons-1.0. All other functionality is implemented by third-party packages included in the list of project dependencies.

Below is a list of packages that come with Pylons-1.0 and Pyramid-1.0a1. The output is obtained using the utilities virtualenv and pip .
')

Standard equipment Pylons

Beaker == 1.5.4
FormEncode == 1.2.3dev
Mako == 0.3.5
MarkupSafe == 0.11
Paste == 1.7.5.1
PasteDeploy == 1.3.4
PasteScript == 1.7.3
Pygments == 1.3.1
Pylons == 1.0
Routes == 1.12.3
Tempita == 0.5dev
WebError == 0.10.2
WebHelpers == 1.2
WebOb == 1.0
WebTest == 1.2.3
decorator == 3.2.0
nose == 0.11.4
simplejson == 2.1.2
wsgiref == 0.1.2

Pyramid standard equipment

Beaker == 1.5.4
Chameleon == 1.2.13
Mako == 0.3.5
MarkupSafe == 0.11
Paste == 1.7.5.1
PasteDeploy == 1.3.4
PasteScript == 1.7.3
WebOb == 1.0
pyramid == 1.0a1
repoze.lru == 0.3
translationstring == 0.3
venusian == 0.4
wsgiref == 0.1.2
zope.component == 3.10.0
zope.configuration == 3.7.2
zope.deprecation == 3.4.0
zope.event == 3.5.0-1
zope.i18nmessageid == 3.5.3
zope.interface == 3.6.1
zope.schema == 3.7.0
- Pylons: 19.
Pyramid: 20.

In quantitative terms, the situation has not changed much - Pyramid, like Pylons, actively relies on third-party technologies and the WSGI stack, but there are structural changes. How hard they affect the complexity of porting a finished Pylons application is hard to say. So far, the developers only mention the reasons that prompted them to make such radical changes ( here in more detail ) and promise over time to provide Pylons 1.x users with a plan for migration to Pyramid without loss of functionality in the applications already created.

UPD: An unofficial migration guide with Pylons-1.0 has appeared online. But the integrity and performance of this decision by the author of the topic has not yet been verified.

UPD: Spherical tests in vacuum .