broken support for python 2.4

[Sven1011]

I have downloaded the latest version of web2py and found that someone
had like the 'all' of python 2.5.

But I wanted to run the framework on centos 5, hence I stuck with 2.4.
After some work I found two main problem files:
./applications/admin/views/default/design.html
./applications/admin/views/default/plugin.html

both files are almost the same and contain the following:
-------------8<-------------------------
while path!=file_path:
if len(file_path)>=len(path) and all([v==file_path[k] for
k,v in enumerate(path)]):
path.append(file_path[len(path)])
thispath='static__'+'__'.join(path)
------------->8-------------------------

if replaced with:
-------------8<-------------------------
while path!=file_path:
idx = 0
while idx < len(path) and idx < len(file_path) and
(path[idx] == file_path[idx]):
idx += 1
pass
if (idx >= len(path)):
path.append (file_path[idx])
thispath='static__'+'__'.join(path)

------------->8-------------------------

web2py works again in my environment. There are other areas where some
had already made the efford to get web2py back to supprt python 2.4,
so I don't know if there is anyone else interested in this fix, but it
is not easy to understand the sense of what is the goal of this code,
so may be there is someone.

I can at least now start to explore the possibilities of this
framework.

[Massimo Di Pierro]

Thank you. This fix will make it in 1.92.2 since we 1.92.* should
support 2.4, but 1.93.* will no longer run on 2.4.
We had a thread about it and not one person spoke in favor of
supporting 2.4.

[cjrh]

On Feb 20, 6:18 am, Sven1011 <sven...@gmail.com> wrote:
> But I wanted to run the framework on centos 5, hence I stuck with 2.4.

If GCC is available, you can build your own version of Python and
install into ~/local. This slice has info for doing that, and
installing other dependencies:

http://web2pyslices.com/main/slices/take_slice/76

Note that getting pysqlite installed can be tricky. I have found that
I need to build the sqlite binaries into ~/local as well, and then
install pysqlite against that.

[LightDot]

There is a bunch of shared hosting providers that still use RHEL/CentOS 5 and have not upgraded python nor they wish to - that's the point of having RHEL/CentOS. You don't manually upgrade or add things.

And on most shared hosting providers you can't install your own version of python. Trying will most likely get you deleted from the server.

[Massimo Di Pierro]

I also have made this case but when it was brought up for discussion
NOBODY spoke in favor of keeping 2.4 compatibility.

Is yours a general statement or is 2.4 critical for you specifically?

[Jonathan Lundell]

I'm curious what the objection of a hosting provider would be to installing a (local) copy of another python version. Why would they care?

[Massimo Di Pierro]

The local install may require virtualenv or gcc which may not be
available and require root permission.

[Jonathan Lundell]

On Feb 20, 2011, at 11:08 AM, Massimo Di Pierro wrote:
>
> The local install may require virtualenv or gcc which may not be
> available and require root permission.

It may not be possible, I suppose, but that's a different matter than the host forbidding it.

[LightDot]

I can't talk about providers in general, but I do run a small hosting company. This is all from our experience, which might or might not be representative.

In shared hosting world, we really need to keep things locked down as much as possible. It's a jungle out there. There is really no sane way to allow any shared hosting customer to compile anything. In our case, there have been various attempts and 100% of them were the bad guys, who got suspended/deleted.

We do offer a choice of python 2.6 on our CentOS 5 servers, though :)

I don't know if an insight in a hosting provider's logic is of any help, but here is how it goes:

- we use an OS with a long term support, in this case RHEL or CentOS
- we try to keep it as close to stock as possible
- if we need something new, we first ask ourselves what this means for the entire line of servers (they are kept identical), all the customers and how much of the support burden will it be in the future
- if a piece of software gets really really old, we reluctantly do a custom upgrade (outside of RHEL) and maintain it.

The problem is that custom versions of software are a (sweet) pain. They cause unforeseen problems, we need to inform all our customers, give them time to prepare, etc. etc. And then it takes vast amounts of time to support it. In reality, we don't have the resources to maintain such software for the prolonged periods, although it's fun. :)

In case of RHEL 5, we really have problems. It simply got quite old, RHEL 6 got delayed way too much. And CentOS 6 has been delayed even more.

As much as we wanted to upgrade PHP, python, etc. years ago, it really couldn't be done while still providing enterprise grade support (we really do try! It's one of the things I'm proud of when it comes to my day job). So, we provide python 2.6 on CentOS 5 only since last August, I think. I'm sure many shared hosts on CentOS 5 still don't, nor they will.

It looks like CentOS 6 (and Scientific Linux 6) will be out in the beginning of this March. Then the majority of web hosts will start phasing CentOS 5 out. That will take some time too...

Like I said in another thread, there is really no way of knowing how many web2py users will have problems with the lack of python 2.4 support. IMHO.

When we upgrade things / break backwards compatibility, we mail all our customers, we wait for feedback, we publish the news on the web page, in the hosting control panel, etc.. And even after all this, there is always someone who didn't know :) It's just the way things are...

I do think that keeping 1.92.x arround for a year or so should do it. And do post notices on the web page. Now! ;)

Sorry for the long post. And thank you all, for the work on web2py. It's appreciated, probably much more than you know.