Pylons and repoze.bfg merge into Pyramid project

The information surfaced due to the rapidly unfolding discussion in the official group of the project . Specifically, it became known that:

• The Pylons web framework, which recently reached the release of 1.0, in its current form stops its development. Despite the fact that full support of the 1.x branch will be carried out for several more years, no architectural changes and 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 technologies that wish to join the community (a similar path is the development of projects under the umbrella “ Pocoo ” , among which we can separately note the Werkzeug WSGI-stack , Jinja 2 template engine and the Sphinx python project documentation system );
• The main technology under 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. There has not yet been an official announcement from the maintainers, but it should be expected in the near future.
It is strongly recommended that you review your plans for using Pylons-1.x.
From the point of view of new projects, it’s obviously worth it now to join Pyramid, or choose any other alternative technology - the same Werkzeug, Django and other frameworks not derived from Pylons.
For those who are currently developing Pylons, there are not many options for further action:

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

For those who, in principle, are interested in the second option, the following is a very concise retelling of what they managed to learn after 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 (interesting, but the existing documentation uses the past tense - “Until the end of 2010, Pyramid was known as repoze.bfg ; it was merged into the Pylons project at the end of 2010 " ). As key characteristics of the project, which received maximum attention, the developers note:

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

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

• The declarative style of setting up web applications through Zope configuration files (ZCML, XML-based format) is supported ...
• ... at the same time, the framework allows you to use the purely imperative approach of Pylons with its INI configs (creating objects manually, setting them in accordance with the parameters of the INI config and then calling the methods of these objects in the right places);
• поддерживается traversal-алгоритм для поиска и вызова обработчика запросов (спуск «от корневого объекта — к — вложенным» по графу model-объектов в строгом соответствии с иерархией, отраженной в запрошенном URL). Подобный подход также применяется в фреймворке CherryPy...
• … в то же время, разрешается использовать стандартный метод маршрутизации URL по шаблону (URL Dispatch), как это сделано в Pylons и Django, а также допустим смешанный подход из traversal-алгоритма и маршрутизации по шаблону;
• Pyramid использует архитектурный шаблон MVC, однако в несколько видоизменённом виде. Так, компоненты «View» и «Controller» объединены в одну сущность «View», которая отвечает за представление хранимых в «Model» данных, но имеет два различных контекста — «View Callable» и «View Handler».
• View Callable is a callable object (function, or class with a specific __call__ method), which is responsible for processing the incoming request. Its closest counterpart in a Pylons application is the action method inside the controller class. Accordingly, the controller class itself is the closest analogue to what Pyramid calls View Handler;
• Like Pylons, the framework does not impose on the developer any specific technologies for storing and managing data.

Pyramid's own code base consists of approximately 5,000 (five thousand) lines of code, versus slightly more than 2,000 lines in Pylons-1.0. All other functionality is implemented due to third-party packages included in the list of project dependencies.

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

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

Standard equipment Pyramid

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, is actively relying on third-party technologies and the WSGI stack, but structural changes are evident. It is hard to say how much they will affect the complexity of porting a finished Pylons application. So far, the developers only mention the reasons that prompted them to make such radical changes (in more detail here ) and promise over time to provide Pylons 1.x users with a plan to migrate to Pyramid without losing functionality in already created applications.

UPD: An unofficial migration guide from Pylons-1.0 has appeared on the network . But the integrity and performance of this solution by the author of the topic has not yet been tested.

UPD:Spherical tests in a vacuum .