6 ms·

TurboGears joins the Pylons Project

65 points by vimes656 16y ago

twymer 16y ago
I was hoping the Pylons blog would have a post about this as well. It's hard to tell what this means for Pylons going forward.
deleted 16y ago
[deleted]
- vimes656 16y ago
  TG2 is using Pylons 1.0 but for the next major release of Pylons, Pylons merged with repoze.bfg becoming pyramid. Now the word Pylons refer to the project where pyramid is being developed. A little confusing but it's explained here: http://docs.pylonshq.com/ http://docs.pylonshq.com/
cookiecaper 16y ago
A bit unsettling for me. I use Pylons on several projects, though I haven't kept up with Pylons news. I really like Pylons because it was to me the best representation of the ideal framework out there; it was flexible and easy to plug in your own stuff, it was not haughty or insistent that you do things a certain way, it did not rewrite Python's whole standard library as many other frameworks practically rewrite the standard libraries of their constituent languages; it just stayed out of my way and let me do things the way I wanted while still providing me the infrastructure to get something published to the web pretty quickly. This blog post seems to indicate that Pylons is going more in the direction of most frameworks with its talk of "full stack" and choosing defaults. Is Pylons going to become a reimplementation of Django? It's a little weird. I don't know why Pylons thinks this is better as a single project.
- deleted 16y ago
  [deleted]
- cd34 16y ago
  I think you're missing what they are doing. Pyramid is repoze.bfg with some of the good things from Pylons added in. Pyramid is much more extensible with hooks. TurboGears will still be a full-stack, Pyramid + their choices for form library, templating, etc. Pyramid is still very light and makes very few assumptions. I think it is better since you've brought together three frameworks and that collective mindshare is going to collaborate rather than compete.
- sankyo 16y ago
  I have been digging into the pyramid docs and writing some toy apps with it trying to learn it, and I think that you will not be disappointed. I am confident that turbogears / tosca widgets will be integrated in such a way that it is loosely coupled and will not get in your way if you do not want to use it. Spend some time reading the pyramid docs - it it totally agnostic for template engines, authentication/authorization, http session implementation, etc. very pluggable. I will say though, that at this point 1.0alpha8, a noob will probably get frustrated, but someone who has worked with pylons / repoze / sqlalchemy can connect the dots. Also, with every alpha release, you can also see the changes to the documentation, which is looking more like django docs (i.e. good) Django fills a certain niche and if it matches your problem, it is a no brainer. If you need a more flexible web framework, look at pyramid.
gst 16y ago
In my opinion this weakens both projects. As the ultimate goal seems to be to build a new framework based on the two, this means that every code you write today using on of those frameworks will be legacy code soon.
- markramm 16y ago
  Well, by some definition of legacy, that's always true. If we are learning, using better techniques, and writing better software every day what we wrote yesterday will be "legacy" code... But I don't think that matters, ther will be upgrade paths, support for pylons 1 and tg2, and more cooperation and focus in the development team.
deleted 16y ago
[deleted]
logic 16y ago
For cross-referencing, this was also submitted here: http://news.ycombinator.com/item?id=2045684 http://news.ycombinator.com/item?id=2045684
stdbrouw 16y ago
The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything. I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to get excited about. Even the documentation for Pyramid, which at first seems beautifully comprehensive and one of the system's strong points, turns out to be an interlinking mess lacking clear explanations of even the very basics of the system. True enough, like Pylons before it, Pyramid is anything but opinionated, which probably makes it a good base platform for the TurboGears devs, but how much will it matter when people will just shrug their shoulders after looking at the landing page, and proceed to download Django or Flask/Werkzeug or, heck, Ruby on Rails? Anyway, regardless of my scepticism, building new stuff and starting new projects is always fun, so hopefully the Pylons project devs enjoy the process.
- clark 16y ago
  Nice trolling.
  - stdbrouw 16y ago
    I kind of expected this response, and the style of writing may be a little provoking, but I think it's a pretty factual assessment of where these projects are headed. Feel free to disagree, though.
    - clark 16y ago
      glad you expected the response -- you're a classic troll; complete with creating a dummy account, the opening line stating a stupidly absurd negative comment, and the closing line with the insinuation that the devs go through all the pain of running a project for their own edification
- chrism 16y ago
  As the author, I'm interested in improving the Pyramid docs. Can you elaborate on your issues with them? Did you notice the tutorials at http://docs.pylonshq.com/pyramid/dev/index.html#tutorials http://docs.pylonshq.com/pyramid/dev/index.html#tutorials (lots of people seem to miss them).
simonw 16y ago
Can anyone expand upon the benefits of repoze.bfg?
- stdbrouw 16y ago
  repoze.bfg used to cater mainly to people from the Zope/Plone-world — less cruft than Zope 2, easier to understand than Zope 3, but the same underlying ideas and mechanisms: object traversal for URL mapping, ZCML for configuration, an aspect-oriented vibe etc. Ian Bicking made some interesting remarks about BFG back in 2008: http://blog.ianbicking.org/2008/11/06/where-next-for-plone-development/ http://blog.ianbicking.org/2008/11/06/where-next-for-plone-d...
forgotAgain 16y ago
Sorry to hear about TurboGears. When I first found it I was very excited to use it. I think they lost a lot of momentum and community trust with the changes made going from version 1 to version 2. I know after that I felt I could not use them because I had no way of knowing if version 3 would be something completely done over again.
dillon 16y ago
I personally think it's a great move. The combination of 2 great frameworks to make something better.
inovica 16y ago
Wow, I'm thoroughly confused as to which way to go with Python and web frameworks now. We do a fair bit of Python work, primarily for back-end processing (our main work is still in PHP) and we've been trying to move more to Python. I did a LOAD of research into frameworks and had chosen to go with Pylons, and then I saw that they were becoming Pyramid. This announcement obviously means three of them are merging together, but it does make me a bit nervous. I want to stick with Python, because I love it, but this is all making my head hurt a little!!! Anyone on here done a load of research/experimentation already and care to help me make some decisions :) ?
- chrism 16y ago
  Considering the three principals of three (previously-separate) systems are congregating around one (Pyramid), doesn't it make your decision a little easier rather than harder?
  - inovica 16y ago
    I know on the surface that it does, but Pyramid isn't ready for production as yet. Also, the secondary issue for me is that I had made a choice to go with Pylons, but that has effectively been abandoned (sorry for the strong word as I appreciate it will be 'maintained' but will never move forward from where it is, and my concern is that after investing considerable time/energy into our project that the same thing could happen. Thanks though - I appreciate that in some respects it does seem an easier choice. I suppose thats where RoR works - they have one main framework to choose from (and a good one) whereas with Python there are a lot.
    - chrism 16y ago
      Pyramid 1.0 final will be out before PyCon US (~ 2 months from now). However, it bears saying that, so far, no alpha release of Pyramid has been bw incompat with the last in any way. As a result, I wouldn't be scared off much by "alpha" in its version designator, at least as an evaluator. The code in Pyramid has existed for almost 2 years now. Every release has 100% statement coverage via unit tests. An alpha of Pyramid is arguably much more stable than many "final" releases of other web frameworks.
sgentle 16y ago
I'm really excited to hear this, especially after the Pyramid announcement earlier in the year. I used to do a lot of Pylons development, and although it was a great framework that gave you a bunch of ways to do just about anything, I always had lot of trouble figuring out the right way. Jarring especially considering the guiding Python principle of "There should be one - and preferably only one - obvious way to do it". As a result, Pylons always felt like a big jumble of modules that were all sort-of right for what you wanted. I'm glad to see some of TG's full-stack opinionism coming into the fold. I hope all this merging will lead to something with the strengths of both projects, like the Rails+Merb merge.
markramm 16y ago
As the current maintainer of TurboGears, I've been thinking a lot about the python web framework world for the last couple of years, and I have been thinking for a long time that there's too much splintering of effort. One choice to solve that problem would be to all join Django, which is widely used, and has an active developer community. But they have a very strong point of view about how web applications should be developed, and as a result django isn't that flexible. So, in the end what we need is a strong alternative to Django that is flexible, uses existing libraries to good effect, and just works. By joining together in the Pylons Project around the Pyramid framework, that's just what we're aiming to do.

65 points by vimes656 16y ago

I was hoping the Pylons blog would have a post about this as well. It's hard to tell what this means for Pylons going forward.

deleted 16y ago

[deleted]

vimes656 16y ago
TG2 is using Pylons 1.0 but for the next major release of Pylons, Pylons merged with repoze.bfg becoming pyramid. Now the word Pylons refer to the project where pyramid is being developed. A little confusing but it's explained here: http://docs.pylonshq.com/ http://docs.pylonshq.com/

cookiecaper 16y ago

A bit unsettling for me. I use Pylons on several projects, though I haven't kept up with Pylons news. I really like Pylons because it was to me the best representation of the ideal framework out there; it was flexible and easy to plug in your own stuff, it was not haughty or insistent that you do things a certain way, it did not rewrite Python's whole standard library as many other frameworks practically rewrite the standard libraries of their constituent languages; it just stayed out of my way and let me do things the way I wanted while still providing me the infrastructure to get something published to the web pretty quickly. This blog post seems to indicate that Pylons is going more in the direction of most frameworks with its talk of "full stack" and choosing defaults. Is Pylons going to become a reimplementation of Django? It's a little weird. I don't know why Pylons thinks this is better as a single project.

deleted 16y ago
[deleted]
cd34 16y ago
I think you're missing what they are doing. Pyramid is repoze.bfg with some of the good things from Pylons added in. Pyramid is much more extensible with hooks. TurboGears will still be a full-stack, Pyramid + their choices for form library, templating, etc. Pyramid is still very light and makes very few assumptions. I think it is better since you've brought together three frameworks and that collective mindshare is going to collaborate rather than compete.
sankyo 16y ago
I have been digging into the pyramid docs and writing some toy apps with it trying to learn it, and I think that you will not be disappointed. I am confident that turbogears / tosca widgets will be integrated in such a way that it is loosely coupled and will not get in your way if you do not want to use it. Spend some time reading the pyramid docs - it it totally agnostic for template engines, authentication/authorization, http session implementation, etc. very pluggable. I will say though, that at this point 1.0alpha8, a noob will probably get frustrated, but someone who has worked with pylons / repoze / sqlalchemy can connect the dots. Also, with every alpha release, you can also see the changes to the documentation, which is looking more like django docs (i.e. good) Django fills a certain niche and if it matches your problem, it is a no brainer. If you need a more flexible web framework, look at pyramid.

gst 16y ago

In my opinion this weakens both projects. As the ultimate goal seems to be to build a new framework based on the two, this means that every code you write today using on of those frameworks will be legacy code soon.

markramm 16y ago
Well, by some definition of legacy, that's always true. If we are learning, using better techniques, and writing better software every day what we wrote yesterday will be "legacy" code... But I don't think that matters, ther will be upgrade paths, support for pylons 1 and tg2, and more cooperation and focus in the development team.

deleted 16y ago

[deleted]

logic 16y ago

For cross-referencing, this was also submitted here: http://news.ycombinator.com/item?id=2045684 http://news.ycombinator.com/item?id=2045684

stdbrouw 16y ago

The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything. I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to get excited about. Even the documentation for Pyramid, which at first seems beautifully comprehensive and one of the system's strong points, turns out to be an interlinking mess lacking clear explanations of even the very basics of the system. True enough, like Pylons before it, Pyramid is anything but opinionated, which probably makes it a good base platform for the TurboGears devs, but how much will it matter when people will just shrug their shoulders after looking at the landing page, and proceed to download Django or Flask/Werkzeug or, heck, Ruby on Rails? Anyway, regardless of my scepticism, building new stuff and starting new projects is always fun, so hopefully the Pylons project devs enjoy the process.

clark 16y ago
Nice trolling.
- stdbrouw 16y ago
  I kind of expected this response, and the style of writing may be a little provoking, but I think it's a pretty factual assessment of where these projects are headed. Feel free to disagree, though.
  - clark 16y ago
    glad you expected the response -- you're a classic troll; complete with creating a dummy account, the opening line stating a stupidly absurd negative comment, and the closing line with the insinuation that the devs go through all the pain of running a project for their own edification
chrism 16y ago
As the author, I'm interested in improving the Pyramid docs. Can you elaborate on your issues with them? Did you notice the tutorials at http://docs.pylonshq.com/pyramid/dev/index.html#tutorials http://docs.pylonshq.com/pyramid/dev/index.html#tutorials (lots of people seem to miss them).

simonw 16y ago

Can anyone expand upon the benefits of repoze.bfg?

stdbrouw 16y ago
repoze.bfg used to cater mainly to people from the Zope/Plone-world — less cruft than Zope 2, easier to understand than Zope 3, but the same underlying ideas and mechanisms: object traversal for URL mapping, ZCML for configuration, an aspect-oriented vibe etc. Ian Bicking made some interesting remarks about BFG back in 2008: http://blog.ianbicking.org/2008/11/06/where-next-for-plone-development/ http://blog.ianbicking.org/2008/11/06/where-next-for-plone-d...

forgotAgain 16y ago

Sorry to hear about TurboGears. When I first found it I was very excited to use it. I think they lost a lot of momentum and community trust with the changes made going from version 1 to version 2. I know after that I felt I could not use them because I had no way of knowing if version 3 would be something completely done over again.

dillon 16y ago

I personally think it's a great move. The combination of 2 great frameworks to make something better.

inovica 16y ago

Wow, I'm thoroughly confused as to which way to go with Python and web frameworks now. We do a fair bit of Python work, primarily for back-end processing (our main work is still in PHP) and we've been trying to move more to Python. I did a LOAD of research into frameworks and had chosen to go with Pylons, and then I saw that they were becoming Pyramid. This announcement obviously means three of them are merging together, but it does make me a bit nervous. I want to stick with Python, because I love it, but this is all making my head hurt a little!!! Anyone on here done a load of research/experimentation already and care to help me make some decisions :) ?

chrism 16y ago
Considering the three principals of three (previously-separate) systems are congregating around one (Pyramid), doesn't it make your decision a little easier rather than harder?
- inovica 16y ago
  I know on the surface that it does, but Pyramid isn't ready for production as yet. Also, the secondary issue for me is that I had made a choice to go with Pylons, but that has effectively been abandoned (sorry for the strong word as I appreciate it will be 'maintained' but will never move forward from where it is, and my concern is that after investing considerable time/energy into our project that the same thing could happen. Thanks though - I appreciate that in some respects it does seem an easier choice. I suppose thats where RoR works - they have one main framework to choose from (and a good one) whereas with Python there are a lot.
  - chrism 16y ago
    Pyramid 1.0 final will be out before PyCon US (~ 2 months from now). However, it bears saying that, so far, no alpha release of Pyramid has been bw incompat with the last in any way. As a result, I wouldn't be scared off much by "alpha" in its version designator, at least as an evaluator. The code in Pyramid has existed for almost 2 years now. Every release has 100% statement coverage via unit tests. An alpha of Pyramid is arguably much more stable than many "final" releases of other web frameworks.

sgentle 16y ago

I'm really excited to hear this, especially after the Pyramid announcement earlier in the year. I used to do a lot of Pylons development, and although it was a great framework that gave you a bunch of ways to do just about anything, I always had lot of trouble figuring out the right way. Jarring especially considering the guiding Python principle of "There should be one - and preferably only one - obvious way to do it". As a result, Pylons always felt like a big jumble of modules that were all sort-of right for what you wanted. I'm glad to see some of TG's full-stack opinionism coming into the fold. I hope all this merging will lead to something with the strengths of both projects, like the Rails+Merb merge.

markramm 16y ago

As the current maintainer of TurboGears, I've been thinking a lot about the python web framework world for the last couple of years, and I have been thinking for a long time that there's too much splintering of effort. One choice to solve that problem would be to all join Django, which is widely used, and has an active developer community. But they have a very strong point of view about how web applications should be developed, and as a result django isn't that flexible. So, in the end what we need is a strong alternative to Django that is flexible, uses existing libraries to good effect, and just works. By joining together in the Pylons Project around the Pyramid framework, that's just what we're aiming to do.