Can Pylons be more aggressive ?
rikl...@gmail.com
Mako. But Pylons has one problem - "what in the nine hells is Pylons
?" - It isn't too popular, which is bad, very bad ;)
I have my sites written in Django and if I used Pylons I most likely
would not find any "free" hosting for it (FOSS sites) and I probably
would had more problems with coding this or that...
1. Hosting possibilities - not to many...
---------------------------------------------
Why not mail various hosting companies that theoretically support
Pylons (like they give ssh+server+mod_python/scgi/fcgi or support
django, TG) and ask them would they want to cooperate. We (Pylons
Project) check if they can host Pylons apps, if not - what needs to
be fixed. Pylons team writes a howto and can make a basic support -
the hosting company adds Pylons to its hosting features etc. maybe
support the project in some way. Also free hosting (or free for
Pylons/FOSS web sites) is a must ;) More hosts on the list the better.
2. Documentation
--------------------------------------------
More docs and in a more friendly layout. In Django to start working
with databases user needs to check two pages - "Creating models",
"The database API " which explain in a nice way how to use that
part of the framework. For this example a Pylons only SQLAlchemy
tutorial would be required (how to add,edit,delete,search, how to make
complex queries, how to create models).
The docs layout could be like django/djangoo book - explain one
feature at a time, no SQLAlchemy + Myghty + Helpers + FooSomething at
once. Lolish examples with print's are very good for learning. Move
tips from mailing list to the site.
3. Promotion
-------------------------------------------
Django writes a book, Django on PyCon, everyone talks about Django ;)
There is a lot of small and bigger Django apps (Check google code).
Pylons can also use some more aggressive promotion - if someone wants
to make a CMS app and ask about it on the mailing lists - no Zope but
"use Pylons"... Blog about Pylons, new tutorials, new events (like
new hosting company etc.) put them on aggregates like python planet.
Try to digg them.
Mike Orr
>
> Pylons is a very nice framework and new features are very good like
> Mako. But Pylons has one problem - "what in the nine hells is Pylons
> ?" - It isn't too popular, which is bad, very bad ;)
It's basically a "put your money where your mouth is" situation.
Contacting hosting companies, more HOWTOs and a book are good ideas,
but somebody's gotta do them.
Pylons' main problem is it's new and not stable yet. Plus it depends
on so many third-party libraries, many of which themselves are new, so
the Pylons developers have to chase down more inter-package issues
than with other frameworks, even TurboGears. This woven-together
approach is one of Pylons' unique strengths but it's arguably more
developer-intensive, meaning less time for marketing until things
stablize more.
It's also worth looking at where Python's web support tools in general
are going. They're evolving rapidly, and many people feel the
Python-web intelligentsia needs to speak with one voice and advocate
one or two frameworks for the casual user, even if it's not the
framework they personally use or develop. Otherwise the py-curious
get overwhelmed by the choices and go with Ruby or Java instead.
Supposedly there are more Rails users than all the Python web
developers combined, and an even larger number of people are doing
their first web project and shopping for a language. It's more
important for us that they choose Python than which Python framework
they choose. Many of them will choose only something that's "like
Rails". TurboGears and Django fill that need now, both in being "like
Rails", having newbie-friendliness as one of their primary goals, and
having that all-important book. But notice that TG and Django did not
even exist two years ago; that's how rapidly things are evolving.
Webware knocked Zope off the throne, CherryPy knocked Webware (with
help from Quixote), TG knocked CherryPy, Django and TG are
neck-in-neck now, who knows who will be top dog next year?
But Pylons will likely be in the top three next year because it fills
a unique niche: the "hackers' framework". There are a considerable
number of users who are less concerned about whether the HOWTOs are
finished than the philosophy of the framework, and they're partial to
the "small sharp tools" philosophy. Small sharp tools that can be
woven together: exactly what made Unix take off in the 70s. Pylons is
"the" WSGI framework. Other frameworks connect to WSGI HTTP servers,
but only Pylons (and standalone Paste) are truly built around WSGI.
That has the potential to bring in lots of web developers down the
road, as more middleware becomes available and people get more
comfortable aggregating multiple mini-applications into a single site.
If Pylons can pull off a newbie-friendly stunt on top of that, it
would corner the market. But we're really just following the lead of
TG and Django in that regard, porting the tutorials they've written,
and I don't see how that can change unless we get a large dedicated
marketing staff like they have. Unless somebody can think of
something spectacular to do that they haven't done. A killer app, for
instance.
I've written some articles looking at Python-web's evolution. None of
them are recent enough to mention Pylons, but the trends they do
discuss are still happening.
http://linuxgazette.net/authors/orr.html
> Also free hosting (or free for
> Pylons/FOSS web sites) is a must ;)
You're dreaming, right? Somebody has to pay the ISP's bandwidth/rent/hardware.
> More docs and in a more friendly layout. In Django to start working
> with databases user needs to check two pages - "Creating models",
> "The database API " which explain in a nice way how to use that
> part of the framework. For this example a Pylons only SQLAlchemy
> tutorial would be required (how to add,edit,delete,search, how to make
> complex queries, how to create models).
> The docs layout could be like django/djangoo book - explain one
> feature at a time, no SQLAlchemy + Myghty + Helpers + FooSomething at
> once. Lolish examples with print's are very good for learning. Move
> tips from mailing list to the site.
If you feel like putting an outline on the wiki, it would encourage
others to fill it in.
--
Mike Orr <slugg...@gmail.com>
Damjan
> ---------------------------------------------
> Why not mail various hosting companies that theoretically support
> Pylons (like they give ssh+server+mod_python/scgi/fcgi or support
> django, TG) and ask them would they want to cooperate. We (Pylons
> Project) check if they can host Pylons apps, if not - what needs to
> be fixed. Pylons team writes a howto and can make a basic support -
> the hosting company adds Pylons to its hosting features etc. maybe
> support the project in some way. Also free hosting (or free for
> Pylons/FOSS web sites) is a must ;) More hosts on the list the better.
I remember a guy on #pythonpaste was planning to submit a project to
Google summer of code for a hosting system for WSGI applications. His
idea, as I remember, was you just upload files via ftp, including a
config file that defines how the app is started and SCGI parameters,
and his system starts the app, sets the virtual hosts and SCGI in the
web server etc...
I don't know what happened with that proposal, but that would be pretty
good for system providers.
rikl...@gmail.com
comercials that offers pylons/python hosting. There is "free" RoR
hosting somewhere - google says ;)
As for docs outlines -
http://groups.google.com/group/pylons-discuss/browse_thread/thread/d16b108ca8b9dcfd/a4925714432b1f9c?lnk=gst&q=workshop&rnum=2#a4925714432b1f9c
;)
Ramon Diaz-Uriarte
of effort on porting our apps to use Pylons (and I've been bugging the
list with a few questions :-). A few comments from that perspective:
On 1/3/07, rikl...@gmail.com <rikl...@gmail.com> wrote:
>
(...)
>
> 1. Hosting possibilities - not to many...
> ---------------------------------------------
(...)
That is not an issue for us (we host things on our machines here,
blablabla). But I understand our situation is not common.
>
> 2. Documentation
> --------------------------------------------
> More docs and in a more friendly layout. In Django to start working
> with databases user needs to check two pages - "Creating models",
> "The database API " which explain in a nice way how to use that
> part of the framework. For this example a Pylons only SQLAlchemy
> tutorial would be required (how to add,edit,delete,search, how to make
> complex queries, how to create models).
> The docs layout could be like django/djangoo book - explain one
> feature at a time, no SQLAlchemy + Myghty + Helpers + FooSomething at
> once. Lolish examples with print's are very good for learning. Move
> tips from mailing list to the site.
Well, this is actually interesting. When we started (about 9 months
ago?), one of the reasons we decided to go with Pylons was that it
looked like the docs were actually better and the info easier to find
(yes, we did look at TG and Django, among several others). We haven't
really compared again after we plunged into Pylons. However, yes,
certainly the docs can be very much improved (e.g., just in the last
couple of days, Mariana has found a solution to a problem not from a
Pylons doc, but from a Ruby on Rails doc, and extrapolating from
there).
(I just read Mike Orr's comments; I see his points, but to those of us
who are not really web-based apps. hackers the situation can sometimes
be _very_ frustrating. That said, though, we still think Pylons is
really awesome).
>
> 3. Promotion
> -------------------------------------------
> Django writes a book, Django on PyCon, everyone talks about Django ;)
> There is a lot of small and bigger Django apps (Check google code).
> Pylons can also use some more aggressive promotion - if someone wants
> to make a CMS app and ask about it on the mailing lists - no Zope but
> "use Pylons"... Blog about Pylons, new tutorials, new events (like
> new hosting company etc.) put them on aggregates like python planet.
> Try to digg them.
>
Our moving to pylons is far from complete, but (some of) our stuff is here:
https://launchpad.net/asterias-pylons
Best,
R.
>
> >
>
--
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz
ToddG
nobody has thought of your suggestions or if they would be good ideas,
it's that they all require time and energy.
1) Hosting - at this point one can generally run pylons anywhere that
supports django or turbogears or in many cases rails (if they have
fastcgi support in addition to mongrel).
If you think back a bit, *nobody* supported Rails when it was first
released, and probably few ISPs even had a recent Ruby install before
Rails-users (authors) basically started a whole new ISP to kickstart it
-- Textdrive(Joyent). As for overall availability, PHP still kicks
everyone's butt. I don't think free hosting is worth anyone worrying
about.
2) Docs -- the bane of most every project, free or non-free. Made more
complicated by the usage of separate libraries -- which are not going
to all be folded into Pylons -- so the ongoing problem is tying the
docs together without reproducing them everywhere (and the
maintainablity problems of that). All of the SQLAlchemy docs are not
going to be reproduced on the Pylons site. Same for any of the
templating choices. While certainly there could be (and will eventually
be) more examples of co-usage of the libs, the docs will always be more
spread out than in "everything in one box" frameworks like django or
rails.
3) Promotion -- aggressive promotion brings its own issues, both good
and bad. Pylons and django I think have pretty different outlooks on
things so comparing their promotion efforts isn't all that helpful.
So, Pylons is still a young chap (and python web programming is still
very volatile), working its way up in the world. More than a few people
have come to it after running into limits in other frameworks, so I
think that will increasingly be an area of growth/attractiveness. Right
now people mostly probably seek out Pylons (even if they don't know
that's what they're looking for, they recognize it when they find it),
maybe in the future it will be in plain view of everyone.
Mike Orr
> As for docs outlines -
> http://groups.google.com/group/pylons-discuss/browse_thread/thread/d16b108ca8b9dcfd/a4925714432b1f9c?lnk=gst&q=workshop&rnum=2#a4925714432b1f9c
> ;)
I've added a "Documentation wish list" page on the wiki for things like this.
http://pylonshq.com/project/pylonshq/wiki/DocumentationWishList
--
Mike Orr <slugg...@gmail.com>
Vitaliy Yermolenko
> So, Pylons is still a young chap (and python web programming is still
> very volatile), working its way up in the world. More than a few people
> have come to it after running into limits in other frameworks, so I
> think that will increasingly be an area of growth/attractiveness. Right
> now people mostly probably seek out Pylons (even if they don't know
> that's what they're looking for, they recognize it when they find it),
> maybe in the future it will be in plain view of everyone.
As for me the best and effective promotion is set of real success
stories in Pylons, and we have to make this as soon as possible
altogether!..
Kendall Clark
On Jan 4, 2007, at 2:21 AM, Mike Orr wrote:
> It's basically a "put your money where your mouth is" situation.
> Contacting hosting companies, more HOWTOs and a book are good ideas,
> but somebody's gotta do them.
I see that raise and call:
I published James Gardner's stuff on WSGI on XML.com last year
precisely to prepare the ground work for some articles on Pylons,
which has become my preferred web framework since around the 0.8.2
release.
I've talked to James about writing a piece about Pylons when it goes
1.0, and I still want to do that (i.e., if James is still interested,
he's got dibbs on the main 1.0 piece). But I'd also publish some
other pieces about Pylons too, so authors for that would be great.
Mike Orr, in particular, seems like a good choice, since I've been
reading his various Py, Web, and Linux things for years now.
Companion pieces on SA and Mako (or, Buffet) would also be welcome.
I'm ken...@xml.com for these purposes, so you guys might want to
throw me some proposals. We generally pay anywhere from $200 to $400,
depending on the article.
Cheers,
Kendall
James Gardner
> I've talked to James about writing a piece about Pylons when it goes
> 1.0, and I still want to do that (i.e., if James is still interested,
> he's got dibbs on the main 1.0 piece).
I'm still up for that. In fact perhaps now that others on the mailing
list seem to think it is time to start pushing Pylons more heavily
perhaps I should get started!
James
rikl...@gmail.com
feature list if they are interested in cooperation to enable
pylons/django hosting on them - I test & write a tutorial - they get a
new feature and link to the howto etc :) I've already got first
positive response...
TazzleNack
> This woven-together approach is one of Pylons' unique strengths
> but it's arguably more developer-intensive, meaning less time for
> marketing until things stablize more.
It's definitely a strength and it's the reason I choose to go with
Pylons myself. I'm a newb when it comes both Python and web
development, but I'm experienced software engineer, and it's been
experience that 1) frameworks become more of bane then a boon as soon
as you go beyond what they do well, 2) I usually develop apps that go
beyond what any existing framework does well. While some folks call
Pylons a framework or light weight framework, personally, I wouldn't,
since it lacks coupling between the different subsytems (i.e. don't
like Routes, fine replace it, want to use your own custom data
provider, fine go ahead, decide you don't like Myghty, go ahead and use
Kid instead, etc.).
> Webware knocked Zope off the throne, CherryPy knocked Webware (with
> help from Quixote), TG knocked CherryPy, Django and TG are
> neck-in-neck now, who knows who will be top dog next year?
Hopefully it will be a framework(s) that is built on top of Pylons.
That way when folks figure out the framework is in their way they'll
hopefully have an easier time working around it.
Stephen F. Steiner
Webware knocked Zope off the throne, CherryPy knocked Webware (withhelp from Quixote), TG knocked CherryPy, Django and TG areneck-in-neck now, who knows who will be top dog next year?
Mike Orr
> Mike Orr wrote:
> Webware knocked Zope off the throne, CherryPy knocked Webware (with
> help from Quixote), TG knocked CherryPy, Django and TG are
> neck-in-neck now, who knows who will be top dog next year?
>
> I'm not sure I'd agree about TG knocking out CherryPy. It's built on
> CherryPy so ipso facto, there's nothing in TG that can't be built on
> CherryPy.
I meant in terms of popularity and visibility, not capability. It's
possible my impression
is wrong in any case; I'm just going by how often I hear of them.
--
Mike Orr <slugg...@gmail.com>
Stephen F. Steiner
Mike Orr
>
>
> On Jan 7, 2007, at 7:10 PM, Mike Orr wrote:
>
>
> On 1/7/07, Stephen F. Steiner <sste...@integrateddevcorp.com> wrote:
> Mike Orr wrote:
> Webware knocked Zope off the throne, CherryPy knocked Webware (with
> help from Quixote), TG knocked CherryPy, Django and TG are
> neck-in-neck now, who knows who will be top dog next year?
>
> I'm not sure I'd agree about TG knocking out CherryPy. It's built on
> CherryPy so ipso facto, there's nothing in TG that can't be built on
> CherryPy.
>
> I meant in terms of popularity and visibility, not capability. It's
> possible my impression
> is wrong in any case; I'm just going by how often I hear of them.
>
> Mike,
>
> I completely agree with your popularity and visibility evaluation.
>
> It's amazing what a little well-executed publicity can do; well-planned or
> not.
Publicity plus having newbie-handholding tools ready to go. These are
related because the works-out-of-the-box thing is what a lot of users
are looking for, and it's what makes them advocate the framework to
their friends. Down the road we should also think about having a
generic database viewer, control panel app, and CMS ready to go, along
with a full-featured blog and wiki (MoinMoin integration?). Other
frameworks have some of these and they draw a certain percentage of
users. They could be in a Super-Pylons-with-Batteries distribution
that easy_installs them and sets up some demonstration app(s).
Again, we're speaking in the context of frameworks for newbies, which
is where all the "high visibility" framework hype is (or at least has
been). The Quixote developers consciously chose not to compete in
this arena and to stick to the niche it's best at: seasoned Python
programmers who want a minimal framework with maximal flexibility.
Pylons is getting advanced Python programmers for the same reason.
Pylons has the potential to reach both markets.
TurboGears has also reached into the maximum-flexibility market in
recent months, so it's possible TG and Pylons will meet each other
halfway, coming from opposite directions. It remains to be seen
whether TG will still have a monolithic CherryPy base at that point,
or whether CherryPy itself will still be as monolithic (I haven't seen
CP 3). There has been experimental work to base TG on RhubarbTart,
which provides a minimal CP-compatible request object and
import-globals on top of a WSGI base.
> I didn't realize how much a screen0-cast could convey; 'till I'd seen a
> few.
The problem with screencasts is they require proprietary codexes to
view. These are a hassle to install on Linux. I had to watch the TG
screencasts on my colleague's Macintosh. Whether you agree with free
software or not, you've got a problem if your marketing materials
can't be viewed by everybody with just a click.
--
Mike Orr <slugg...@gmail.com>