Which Python web framework is most like Ruby on Rails?

[Mike Meyer]

Indeed. Large portions of a lot of Web sites could actually be deployed
statically, rather than hitting a database several times a page to
retrieve stuff which changes once in a blue moon. Moreover, static page
hosting is generally a lot cheaper than dynamic program hosting.

And with the proper technology, you can get the best of both
worlds. You build the site as dynamically genrated, then "compile" it
to get the static pages you actually serve. That way you get all the
benefits you listed of serving static pages, plus the ability to use a
database and all it's associated tools for maintaining your data (if
you consider that an advantage, anyway).

<mike

 

[Steve Holden]

And with the proper technology, you can get the best of both
worlds. You build the site as dynamically genrated, then "compile" it
to get the static pages you actually serve. That way you get all the
benefits you listed of serving static pages, plus the ability to use a
database and all it's associated tools for maintaining your data (if
you consider that an advantage, anyway).

That's an approach I'm currently experimenting with - the content of
www.holdenweb.org is mostly static but generated from a database, and
the current tasks include completing a wxPython database maintenance
GUI, incorporating various ways to generate scripted content that
matches the look and feel of the rest of the site and adding more and
more ways to generate the interior content.

It's obvious by comparison with www.holdenweb.com that there's a good
deal of design commonality.

I'll be looking for beta testers eventually ...

regards
Steve

 

[Kent Johnson]

The only problem with KARRIGELL, I guess, is that its creator is very
humble and doesn't like to advertise his creature. He is not very fond
of "marketing" ...

From my point of view the biggest problem with Karrigell is that it is released under the
GPL. Most of my projects at least have the potential of being distributed to customers and
GPL is not an option.

Kent

 

[Russell E. Owen]

Perhaps it's off-topic for this thread, but I think "picking a database"
is the first mistake most people make. It's a form of premature
optimization.

I just wanted to point out that I was responding to somebody who
complained that the database interface situation on python was somewhat
fragmented.

Also, when I was looking at web frameworks, I was doing so *precisely*
to serve one or more databases of information (read only to the users,
but occasionally loaded with more info as it became available). So it
happened to be the first question I asked (at the same time as "and how
do I talk to it?").

Anyway, you did warn that your message was possibly off-topic, so I
guess I'm agreeing with you and perhaps being overly defensive. It was
an interesting message.

-- Russell

 

[Luis M. Gonzalez]

I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

 

[Luis M. Gonzalez]

From my point of view the biggest problem with Karrigell is that it is released under the

GPL. Most of my projects at least have the potential of being distributed to customers and
GPL is not an option.

I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

 

[Paul Rubin]

Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

See:
http://www.gnu.org/philosophy/pragmatic.html

 

[Michael Tobis]

Clearly the Ruby/Rails folks are making an effort to place themselves
as an easy-to-learn first language for people who might otherwise drift
into the rather awkward template-first way of thinking that is PHP.

I note that the Rails people are closely affiliated with the 37signals
people who in turn are closely linked with some advertising
professionals.

Python people don't really think that way. As a community we really
seem to inherit the open source dysfunction of trying harder to impress
each other than to reach out to the rest of the world. The problem is
that this makes for amazing brilliance that is more or less invisible
to most of the world.

This leaves me believing that the commercial future is probably
brighter for Ruby vs Python. This won't affect the fact that Python is
probably still going to prevail in the scientific community, since
scientists aren't all that susceptible to promotion. That being the
case I don't think I myself will jump ship.

Since I am casting my lot with Python rather than Ruby, I think we
should take the friendly rivalry seriously rather than just shrugging
it off. Python MUST attract some of the most promising novice
programmers, and I believe that was part of its original design.

As a consequence Python MUST settle on a strong web framework that
includes the best of the existing frameworks, and polish it for maximum
accessibility as well as power.

Just on the basis of momentum rather than any strong technical argument
(which I am not well-qualified to make) I suggest we consider settling
on Django and doing what we can to improve it and its documentation.

mt

 

[Kent Johnson]

I don't think Pierre (Karrigell's creator) is awared of licenses and
legal issues.
Perhaps you can tell us what's the problem with GPL and, if possible,
propose an alternative...

OK I'll try. First let me say I have no interest in a licensing flame war, there are valid
reasons why an author might prefer one license over another and certainly there are good
reasons to choose GPL. However the work I do is commercial and proprietary and I doubt I
could get approval to release it under GPL. So I am restricted to projects with more
liberal licenses such as MIT, BSD and Apache licenses. These allow closed-source
distribution of products based on them.

Certainly it is within an author's rights to prohibit use of his code in closed source
products, as the author of Karrigell has done by choosing GPL and I respect this decision.
Unfortunately this makes it impossible for me to consider using Karrigell in my work. I
recently needed a stand-alone web server for a small in-house project that might possibly
be distributed to business partners or become a product some day. I chose CherryPy in part
because its license allows this. I would have considered Karrigell if it had a different
license.

Kent

 

[Paul Rubin]

I chose CherryPy in part because its license allows this. I
would have considered Karrigell if it had a different license.

Have you had to modify CherryPy in some substantive way that you
needed to keep proprietary, as opposed to simply developing content
that CherryPy serves but is completely independent of CherryPy's
license?

I notice that a heck of a lot of commercial users are using completely
proprietary packages like ASP, whose licenses are far more restrictive
than the GPL. They don't seem to think it's a problem. So for most
such users, Karrigell shouldn't be a problem either. Remember that
the GPL only applies to the code of Karrigell itself, not to stuff
that you write using it.

 

[Kent Johnson]

Have you had to modify CherryPy in some substantive way that you
needed to keep proprietary,

I did make some changes to CherryPy. I wouldn't mind sharing those changes back with the
CherryPy community. But the product was the server itself, not the web site. As I
understand the GPL the server software would be a "work based on the [GPL-licensed]
Program" and thus subject to the GPL itself.

> as opposed to simply developing content
> that CherryPy serves but is completely independent of CherryPy's
> license?

I'm not sure what you mean by "simply developing content". I was developing a web
application, not a web site serving static HTML. The bulk of the development work was
writing Python code that worked with CherryPy.

I notice that a heck of a lot of commercial users are using completely
proprietary packages like ASP, whose licenses are far more restrictive
than the GPL. They don't seem to think it's a problem. So for most
such users, Karrigell shouldn't be a problem either.

Building a website using Karrigell is not a problem because the work is not distributed.
Distributing a webserver based on Karrigell as a product would require the server to be
GPL licensed.

Remember that
the GPL only applies to the code of Karrigell itself, not to stuff
that you write using it.

IANAL but that is not my understanding of the GPL. GPL version 2 section 2.b) reads, "You
must cause any work that you distribute or publish, that in whole or in part contains or
is derived from the Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would certainly be a work
that in part contains Karrigell.

Kent

 

[Paul Rubin]

I did make some changes to CherryPy. I wouldn't mind sharing those
changes back with the CherryPy community. But the product was the
server itself, not the web site. As I understand the GPL the server
software would be a "work based on the [GPL-licensed] Program" and
thus subject to the GPL itself.

Yes, correct.

I'm not sure what you mean by "simply developing content". I was
developing a web application, not a web site serving static HTML.

Yes, that is content.

The bulk of the development work was writing Python code that worked
with CherryPy.

And also with the Python interpreter. If the Python interpreter were
GPL'd, would that have been an issue?

IANAL but that is not my understanding of the GPL. GPL version 2
section 2.b) reads, "You must cause any work that you distribute or
publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to
all third parties under the terms of this License." My server would
certainly be a work that in part contains Karrigell.

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

 

[Mike Meyer]

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

That's one test. Another one is whether you can distribute your app as
one piece and let them get Karrigell from somewhere else to put things
together. If they can set up your app without copying parts of
Karrigel into it (and you didn't do that for them), then you're
ok. You can even bundle Karrigel into the distribution for them.

While them having to modify Karrigel extensively to work with your app
- for instance, if you distributed patch files - is within the letter
of the license, the FSF considers such a violation. IIRC, they gave
NeXT shit for doing this.

<mike

 

[Kent Johnson]

Your web app and html files would IMO be considered a separate work,
like C programs that you compile with GCC. If they don't contain actual
Karrigell code and they're not derived from Karrigell code, then I'd
think 2.b) doesn't apply. The test I'd use is, imagine you don't have
the Karrigell distro and you only have a printout of the documentation.
Can you write your app from just the docs? IANAL, etc., and to be
safe, you could simply ask the Karrigell author.

You've lost me here. The server certainly would contain Karrigell code, it wouldn't
function without it. I don't understand the analogy to GCC, the web site is not something
that is compiled with Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without Karrigell.

A FAQ entry attempts to shed light on the question but just confuses me more. "If the two
programs remain well separated ... then you can treat them as two separate programs--but
you have to do it properly. The issue is simply one of form." WTF?
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

I confess, one reason I stay away from the GPL and even LGPL is because no matter how many
times I read them I'm not sure what they really say. FAQs like the above certainly don't
help much. In contrast the (BSD-style) CherryPy license is crystal clear.

Kent

 

[Paul Rubin]

You've lost me here. The server certainly would contain Karrigell
code, it wouldn't function without it. I don't understand the analogy
to GCC, the web site is not something that is compiled with
Karrigell. Karrigell is a library or framework that is an essential
part of the server. I don't know how I would write the app without
Karrigell.

Let me ask it this way: suppose you used ASP instead. As I understand
ASP, it's like PHP except it's proprietary. Would ASP's license be a
problem?

Maybe you're using "the server" to encompass too much. If I have an
Apache-based web site, then the web server is Apache. If I have a
Python CGI script that the Apache server runs, the CGI script is not
"the server"--it's an application running under the server. It would
not be affected by the GPL if Apache used the GPL. Karrigell scripts
seem to me to work out about the same way.

 

[Steve Holden]

OK I'll try. First let me say I have no interest in a licensing flame war, there are valid
reasons why an author might prefer one license over another and certainly there are good
reasons to choose GPL. However the work I do is commercial and proprietary and I doubt I
could get approval to release it under GPL. So I am restricted to projects with more
liberal licenses such as MIT, BSD and Apache licenses. These allow closed-source
distribution of products based on them.

I see the GPL is a problem in this environment, and you are clearly
aware of the issues it raises. Do be aware, though, that not all GPL
authors are rabid communists, and some will consider licensing to you
under other licenses if you ask them. It's always worth asking, as some
authors have chosen GPL in a somewhat uninformed way rather than as a
political statement (you'll notice I too am trying to avoid the flame wars).

Certainly it is within an author's rights to prohibit use of his code in closed source
products, as the author of Karrigell has done by choosing GPL and I respect this decision.
Unfortunately this makes it impossible for me to consider using Karrigell in my work. I
recently needed a stand-alone web server for a small in-house project that might possibly
be distributed to business partners or become a product some day. I chose CherryPy in part
because its license allows this. I would have considered Karrigell if it had a different
license.

As we say in Yorkshire, "You get nowt if you don't ask".

regards
Steve

 

[Paul Rubin]

I see the GPL is a problem in this environment, and you are clearly
aware of the issues it raises. Do be aware, though, that not all GPL
authors are rabid communists, and some will consider licensing to you
under other licenses if you ask them. It's always worth asking, as
some authors have chosen GPL in a somewhat uninformed way rather than
as a political statement (you'll notice I too am trying to avoid the
flame wars).

I'm trying to avoid flame wars too, but my take on this is that Kent's
reading is a little too restrictive and the GPL isn't really a problem
in this situation unless he's actually modifying Karrigell itself,
rather than writing applications that run under it. I'm not trying to
advocate Karrigell (I browsed the docs for a minute and it looks nice
but I have no experience with it) but I don't see the GPL as an
obstacle to that type of usage. All kinds of proprietary applications
are written and distributed all the time to run under the GPL'd Linux
kernel and Karrigell apps don't seem too terribly different from that.

 

[Pierre Quentel]

Hello all,

I am Karrigell's author. I have chosen the GPL licence almost at random
(I saw that the Python licence was GPL-compatible), so I don't mind
switching to another Open Source licence if the GPL is liable to cause
problems. Which one would you advice : BSD ? Python licence ? another ?

Regards,
Pierre

 

[Paul Rubin]

I am Karrigell's author. I have chosen the GPL licence almost at random
(I saw that the Python licence was GPL-compatible), so I don't mind
switching to another Open Source licence if the GPL is liable to cause
problems. Which one would you advice : BSD ? Python licence ? another ?

My own hope (not shared by everyone obviously) is that you will stay
with the GPL, but make clear that applications that simply run under
Karrigell but don't modify the Karrigell code aren't subjected to the
GPL. That should satisfy Kent's concerns.

See http://www.gnu.org/philosophy/pragmatic.html for some reasons to
use the GPL.

French version: http://www.gnu.org/philosophy/pragmatic.fr.html

 

[Steve Holden]

I'm trying to avoid flame wars too, but my take on this is that Kent's
reading is a little too restrictive and the GPL isn't really a problem
in this situation unless he's actually modifying Karrigell itself,
rather than writing applications that run under it. I'm not trying to
advocate Karrigell (I browsed the docs for a minute and it looks nice
but I have no experience with it) but I don't see the GPL as an
obstacle to that type of usage. All kinds of proprietary applications
are written and distributed all the time to run under the GPL'd Linux
kernel and Karrigell apps don't seem too terribly different from that.

Indeed. But most software authors aren't lawyers and aren't likely to
trust their own judgment about these matters unless the situation is
pretty unambiguous. I suspect this may be evidence that Microsoft's
"viral" propaganda has had some effect.

In this case I agree there's likely to be a clear separation between
server and content that will allow Kent to distribute an unmodified
Karrigell and a separate proprietary content bundle without
interference, but it's too late (at least for that project) now.

regards
Steve