pylons future plans?
Iain Duncan
the website to what the future plans & current work on pylons is. (I
realize of course that now is a bit of an unwind post 0.9.7/new
website/book time. )
I'm in the process of picking my base framework for a long range tool
suite, and knowing what direction pylons will be taking or what will be
coming down the pipe in the future would be helpful. I think it would be
useful as a marketing tool for pylons too.
Thanks for all the work!
Iain
Mike Orr
There is a roadmap but it has gotten out of date.
http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0
I don't know what Ben has up his sleeve but I think the core is
essentially done with 0.9.7. The main incremental changes are on the
periphery: improve @validate, replace @beaker_cache, improve the
dependency documentation. I had a second job which sucked up all my
time, and I'm just now getting back into programming.I expect the
other developers have likewise been working on other stuff.
There was a lot of discussion at PyCon about WSGI 2 and a new
framework. I don't think either of those have gotten anywhere. There
were some ideas to make a Pylons-like framework on top of
zope.component alongside repoze.bfg, but it seems like the main people
who wanted to integrate them each had a different idea about what
level should be integrated and why. Which means maybe it's just
better to leave them as they are because they're working.
--
Mike Orr <slugg...@gmail.com>
Iain Duncan
> On Sat, Jun 20, 2009 at 4:36 PM, Iain Duncan<iaind...@telus.net> wrote:
> >
> > Hey guys, wondering if I could request perhaps a bit more attention on
> > the website to what the future plans & current work on pylons is. (I
> > realize of course that now is a bit of an unwind post 0.9.7/new
> > website/book time. )
> >
> > I'm in the process of picking my base framework for a long range tool
> > suite, and knowing what direction pylons will be taking or what will be
> > coming down the pipe in the future would be helpful. I think it would be
> > useful as a marketing tool for pylons too.
> >
> > Thanks for all the work!
> > Iain
>
> There is a roadmap but it has gotten out of date.
>
> http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0
>
> I don't know what Ben has up his sleeve but I think the core is
> essentially done with 0.9.7. The main incremental changes are on the
> periphery: improve @validate, replace @beaker_cache, improve the
> dependency documentation. I had a second job which sucked up all my
> time, and I'm just now getting back into programming.I expect the
> other developers have likewise been working on other stuff.
Thanks Mike. I think for marketing purposes, it's pretty important that
this kind of stuff be kept up to date. A lot of people checking Pylons
out are going to want to make sure it isn't just going to 'stop' even
though the stability is also a huge selling point.
>
> There was a lot of discussion at PyCon about WSGI 2 and a new
> framework. I don't think either of those have gotten anywhere. There
> were some ideas to make a Pylons-like framework on top of
> zope.component alongside repoze.bfg, but it seems like the main people
> who wanted to integrate them each had a different idea about what
> level should be integrated and why. Which means maybe it's just
> better to leave them as they are because they're working.
Mmm, I was following that on pypefitters and am disappointed that
efforts to continue seem to be being abandoned. I sure hope those
involved decide it's worthwhile after all.
Thanks for the update
Iain
Ben Bangert
>> I don't know what Ben has up his sleeve but I think the core is
>> essentially done with 0.9.7. The main incremental changes are on the
>> periphery: improve @validate, replace @beaker_cache, improve the
>> dependency documentation. I had a second job which sucked up all my
>> time, and I'm just now getting back into programming.I expect the
>> other developers have likewise been working on other stuff.
Yep, that and wipe out the legacy code, which is actually about 1/3rd
of the Pylons 0.9.7 code-base.
> Thanks Mike. I think for marketing purposes, it's pretty important
> that
> this kind of stuff be kept up to date. A lot of people checking Pylons
> out are going to want to make sure it isn't just going to 'stop' even
> though the stability is also a huge selling point.
Yes, it does become tricky on "what to sell" in the way of 'new' when
the scope of the framework is complete, and its mature. One of the
issues is that Pylons itself isn't very plugin-compatible, and even
Django's methodology of "plugin apps" is having issues scaling with
conflicting settings.py files and such.
> Mmm, I was following that on pypefitters and am disappointed that
> efforts to continue seem to be being abandoned. I sure hope those
> involved decide it's worthwhile after all.
Oh, the effort is still continuing. We're kicking around a new and
small little framework called Pypes at the moment, that is designed
for pluggable apps, components, etc. from the get-go in a way that
scales to large numbers of plug-ins and settings. I believe this would
keep with the philosophy of being flexible, while allowing much better
re-usability between websites like how the Django apps allow a manner
of re-usability.
I'll post updates as we make more progress.
Cheers,
Ben
Iain Duncan
Thanks Ben, that is great to hear! Some form of blog on the pylons site
about what's going in the future would be awesome if you have the time.
Iain
Kyle VanderBeek
> On Jun 21, 2009, at 12:40 PM, Iain Duncan wrote:
>
> >> I don't know what Ben has up his sleeve but I think the core is
> >> essentially done with 0.9.7. The main incremental changes are on the
> >> periphery: improve @validate, replace @beaker_cache, improve the
> >> dependency documentation. I had a second job which sucked up all my
> >> time, and I'm just now getting back into programming.I expect the
> >> other developers have likewise been working on other stuff.
>
> Yep, that and wipe out the legacy code, which is actually about 1/3rd
> of the Pylons 0.9.7 code-base.
repo and start sending in patches:
http://pylonshq.com/project/pylonshq/ticket/622
:-)
Christoph Zwerschke
> Fixing the "Contributing" link might help others clone the "official"
> repo and start sending in patches:
I've already reported this several times, but nobody cared. This was
indeed not very encouraging for me.
It's also unclear which of the related/sub projects (webhelpers etc.)
have their own repos, where they are, where to report errros for these,
send in patches etc.
-- Christoph
Mike Orr
Yikes. It seems to be a casualty of the move to BitBucket and Sphinx.
I wrote a new manual for Routes months ago but I'm not really sure
how to integrate it into the new structure, and in any case I don't
have write permission to. BitBucket projects don't really have a home
page except their wiki section, which is lame and hard to find, so the
old home pages have remained even though they're out of date and have
out-of-date links. I'm planning to write a WebHelpers manual, which
will be easier because there's no existing documentation to work
around (except the docstrings), but again the issues of how to
integrate this with the Python docs and what to do about the lame home
page (http://bitbucket.org/bbangert/webhelpers/wiki/Home) come up.
I can update the roadmap this weekend now that we've confirmed there
are no other major changes planned, but Ben will have to update the
Pylons site. Do we have a target release date for the next version?
--
Mike Orr <slugg...@gmail.com>
Mike Orr
over how the documentation is structured and make some decisions on
how the subprojects should integrate with the Pylons site and a common
format for them so they're not all going off in different directions
depending on who's writing them.
--
Mike Orr <slugg...@gmail.com>
Domen Kožar
Iain Duncan
IMHO this is critical to fix!
iain
Iain Duncan
That sounds promising. Do you want user feedback on the docs/examples? I
and two of my people will be doing a lot of pylons learning in the next
month for some projects.
Is it possible to remove the website dependency on Ben only? Would it
not be better if more people were able to fix issues quickly? Just a
thought.
Iain
>
Kyle VanderBeek
there be a a page that tells people the hg clone URL that is best to
start from. If people can't get the code, they can't submit patches
to our benevolent dictator. Without this, there is little hope for
momentum built from community involvement. Sub-projects aside, we at
least need one for Pylons' core.
Iain Duncan
for sure.
iain
Graham Higgins
Hash: SHA1
On 23 Jun 2009, at 02:18, Kyle VanderBeek wrote:
> Fixing the "Contributing" link might help others clone the "official"
> repo and start sending in patches:
Given that the source for the PylonsHQ website itself is on bitbucket:
http://bitbucket.org/bbangert/kai
perhaps Ben is amenable to contributions in that arena.
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkpBN5oACgkQOsmLt1NhivyGxwCgzhceOfHaLgh3VeqPV1qbKY81
Ty4AoPfTOPbDgfVDJDQgt6Dx2oS+3lkhiQCVAgUBSkE3mlnrWVZ7aXD1AQIAIgQA
z7ZbIhs8ER+3e7yvvPQrCU2uFkxBcwB0Cba3t3HXpfNsCWpOlsqxNEMqECxnldRS
h9gOmvV+cBdDEDdeTWbpODw41qMZJL5yP5WX8gsJcgyeM/N7q745UZ9Sn87Z26f/
7qjWgVnmgNm5/4T3eCsUZmyBJSdAmHqKZ5zmi6Q/sQA=
=BM9J
-----END PGP SIGNATURE-----
Mike Orr
>
> On Tue, 2009-06-23 at 06:25 -0700, Mike Orr wrote:
>>
>> Perhaps we could have an IRC documentation party this Saturday and go
>> over how the documentation is structured and make some decisions on
>> how the subprojects should integrate with the Pylons site and a common
>> format for them so they're not all going off in different directions
>> depending on who's writing them.
>
> That sounds promising. Do you want user feedback on the docs/examples?
Well, mostly I need Ben's feedback on where things should go and how
it's structured.
As for patches, I'm not sure that's the bottleneck. There's little to
do in the Pylons core, so what would all these patches cover? Maybe
they'd be rejected as bloat or not the way the developers want to
implement things. And anybody can make a public fork of a BitBucket
repository and implement their changes there, and then petition Ben to
pull the changes. That also allows others to install the alternate
Pylons version if they want to.
> Is it possible to remove the website dependency on Ben only?
Philip can also make changes on the website.
> Given that the source for the PylonsHQ website itself is on bitbucket:
> http://bitbucket.org/bbangert/kai
Well, yes it's there, but what do you do with it? What are the
standards for third -party docs such as Routes and WebHelpers that
need to be both standalone, on their own website, and integrated with
the Pylons docs? What are the markup codes he's using for variable
names and such?
--
Mike Orr <slugg...@gmail.com>
Iain Duncan
> > Mmm, I was following that on pypefitters and am disappointed that
> > efforts to continue seem to be being abandoned. I sure hope those
> > involved decide it's worthwhile after all.
>
> Oh, the effort is still continuing. We're kicking around a new and
> small little framework called Pypes at the moment, that is designed
> for pluggable apps, components, etc. from the get-go in a way that
> scales to large numbers of plug-ins and settings. I believe this would
> keep with the philosophy of being flexible, while allowing much better
> re-usability between websites like how the Django apps allow a manner
> of re-usability.
> I'll post updates as we make more progress.
Is there a mailing list or something where we can follow these
discussions?
Thanks
Iain
Ben Bangert
> Philip can also make changes on the website.
If others would like to help out with documentation (applying fixes
for the comments on the website docs), I'd be happy to give some
others the upload key. Docs can be regenerated using Sphinx, and
uploaded to the website using the included upload script in the pylons
source without anyone else needing to be present (its part of the
PylonsHQ code-base to accept and replace the docs with uploaded ones).
For the website, if there's patches for that, I'd be happy to apply
them as well.
> Well, yes it's there, but what do you do with it? What are the
> standards for third -party docs such as Routes and WebHelpers that
> need to be both standalone, on their own website, and integrated with
> the Pylons docs? What are the markup codes he's using for variable
> names and such?
I've gotten the Beaker site up to date. I can do the same with the
Routes one as well, just need to fix-up the styling and such. If
someone else has more time to throw at this, what needs to be done:
1) Copy over template files from beaker's docs dir so that the Routes
docs get setup and styled
2) Update the index template to be appropriate for Routes
3) Let me know via a pull request, and I'll apply and upload to
routes.groovie.org
I believe that's about it, oh, and maybe the Sphinx module docs need
to be updated. Once Sphinx can generate it, I can go ahead and replace
the routes.groovie.org site with it.
Anyone up for these tasks, or interested in updating the pylons/docs
based on the comments, or fixing any website bugs?
Cheers,
Ben
Ben Bangert
> Is there a mailing list or something where we can follow these
> discussions?
Most of the discussions have taken place on IRC, and a bit took place
at PyCon, as it seems to take too long with too many misunderstandings
when its all done via e-mail threads (Maybe Wave would change that! ;).
Summary of where we've gotten in the past few days for those curious,
but first, a warning. This is future-framework type stuff, Pylons
isn't going anywhere as its a solid project at this point. Pypes and a
future framework will have a migration path for Pylons users, and its
quite possible for many, there won't be any reason to migrate as
Pylons does all they need it to now.
We (Chris McDonough and myself) have been exploring a core system from
which to start with a flexible component oriented framework. So far,
some of it is in the pypes code-base here, though its incredibly
prototype-ish: http://bitbucket.org/chrism/pypes/
It's rather different at the moment from Pylons, and somewhat similar
to repoze.bfg. It uses zope.interface and repoze.component to handle
having pluggable components, though a user would never see such a
thing (only a component developer that needs to make plugins). It's
being designed from the ground up to handle having plug-in apps (an
area I think Pylons fails at, and Django isn't scaling well to handle
with settings.py conflicts and issues).
This means it supports things like being able to plug-in an app, that
needs to register some routes with the main mapper. One of my example
plug-in's/components, was being able to write a XMLRPC Blog backend
'app', that I could easily use in any content-type app, merely by
supplying a path for it to answer on, and giving it an object it needs
to know how to store/retrieve/update the content it should handle.
I feel the XML approach of repoze.bfg and Zope-type apps using ZCML
would be a major turn-off to the user audience, so I've been keen to
go with YAML for configuration. It also has the nice advantage that
YAML structures get parsed directly into Python dictionaries, and
things like true/false, and integers also become proper Python types
auto-magically.
Chris wrote up a YAML based plugin to handle parsing the configuration
file (I'm referring to application/site configuration, stuff thats
currently split into environment.py, routing.py, and middleware.py). I
like it, but of course, some may not, here's what setting up a few
Routes-style connections might look like:
--- !pypesviews
- path: /search/{keyword}
view: myapp.views:Search
action: search
- path: /search
view: myapp.views:Search
action: index
- path: /
view: myapp.views:Home
action: index
etc.
Of course, it'd also be easy to have a default scheme to remove the
need to manually specify where the controller (called view in this
case) actually is. It's also a lot easier to make things flexible with
this layout. For example, the bit at the top of this section, "--- !
pypesview" is a YAML processor directive. The way Chris set it up,
which I think works out quite nicely, is that possible directives are
discovered using setuptools entrypoints. As the applicaiton config
file is parsed, each directive is called with the section under it, so
you will prolly have multiple sections, one for the routing stuff,
maybe a few for plug-in apps or components you're using (they can
register their own directives for use in your config file), etc.
This would let me as a component maker write a XMLRPC backend app that
answers all the common API's (Blogger, Metaweblog, MovableType, etc),
and register a directive, so someone using it could just do:
--- !blog-backend
path: /backend/xmlrpc
object: myapp.lib.apis:XMLRPC
In this case, I'd make my directive look for and import the object,
which would be expected to provide some methods (basic CRUD style), so
that the XMLRPC code would be able to do what is requested. Just a
theoretical sample, but the goal is to make it as easy as possible to
use and create a wide array of flexible components and/or plug-in type
apps, without nearly as many of the restrictions or presumptions in a
Django type system.
Some differences from Pylons:
- Pypes would have no globals of its own (migration adapters would be
available that populate Pylons style globals for a smoother transition)
- Pypes calls the code that handles being dispatched to, a 'view'. I
personally don't care that much anymore what its called, as the terms
MVC definitely doesn't work well in webapps to begin with, especially
since the thing that actually handles and determines what responds to
the request is the URL resolver/dispatcher, NOT the Pylons
'controller', though it of course has a say in what happens to an
extent as well
- Pypes dispatcher uses a Routes mapper first, with 'fall-through' to
traversal (repoze.bfg/zope style, though for backwards compat with
TG2, could use a CherryPy style traverser)
Anyways, that's about where we are now, and we're now working on some
code to play with these thoughts and see how they pan out.
Cheers,
Ben
Iain Duncan
Thanks Ben, that's very exciting. It would be cool if the discussion
could be posted somewhere even as irc transcripts just to keep it more
public. I imagine a focus point will come up soon enough.
Even though it is all future thinking, this does make a difference to
Pylons marketing. For example, I'm now 100% sure I want to keep using
both Pylons and learning BFG, instead of wondering what the future will
bring!
Iain
Iain Duncan
> Thanks Ben, that's very exciting. It would be cool if the discussion
> could be posted somewhere even as irc transcripts just to keep it more
> public. I imagine a focus point will come up soon enough.
well silly me, there it is on the front page of the pypefitters union. I
had only been looking at the email page. =)
iain
Iain Duncan
never mind, that says 2008, so where is the new one? ;-)
iain