On Friday, June 7, 2013 3:36:49 AM UTC+2, Anthony wrote: > > For example, I need web2py to provide python 2.6 compatibility for at >> least another 5 years. I'm going to need python 2.7 compatibility for at >> least another 10 years if not longer. > > > I don't know if your particular application(s) make use of many other > Python libraries, but if they do, then you also need those libraries to > maintain Python 2 compatibility for the next 10 years (or you have to fork > and maintain them yourself, which may work for you). Of course this will > vary by application, but in many cases, there will come a point at which it > will be easier to port the app code to Python 3 than to try to keep hanging > on to Python 2. > I solve this by using distributions with long term support [1], respins of Red Hat. I have customers that opt for Red Hat itself when they don't want to let us handle the OS. Current RHEL 6 will be supported until 2023 and I'll have to support web2py applications with python 2.6 compatibility at least until 2017 if not longer. We guarantee this for our products.
It would be hard for me to justify the price of supporting forked libraries. I opt for EPEL [2] packages when I absolutely must and I fork something when I'm truly paid to support it, although I personally don't like doing it. It's a lot of work if one wants to do it properly. I'm looking into Red Hat software collections [3] and how these will change the support options we could provide... But that's only 3 years of support as it stands now. Also, breaking backward compatibility by merely switching to Python 3 isn't > the same as breaking backward compatibility by changing the web2py API. > There are tools to automate the process of converting application code from > Python 2 to 3 that will get you most of the way. Most of the > web2py-specific code would presumably remain unchanged. > This is a good point. When Massimo laid out plans for web3py, certain web2py compatibility at the app level reassured me that choosing web2py as our preferred tool of trade was a good choice. > Anyway, I agree that the ideal would be a web3py that works with both 2.7 > and 3.x and that runs legacy web2py apps as well. > Yea, I imagine it would cover most of the users of web2py. As for me, I know RHEL 7 will carry python 2.7.x. It could carry python 3.x too and I assume it will, but that's just a guess. When I started participating in the web2py community, I was pretty surprised to see how much Ubuntu gets used for the server/VPS OS of choice. I guess current trends demand for short lived app instances. Contemplating about using Fedora as deploy / destroy / deploy instance [4] is a good case for this trend. But to be perfectly honest, I don't see how anyone could provide actual support in such a volatile environment. I imagine if Dante was writing today, there would be a circle in hell where sysadmins would need to support environments with forked ruby gems, python libs, etc. for the eternity. :) Regards, Ales [1] https://access.redhat.com/support/policy/updates/errata/ [2] http://fedoraproject.org/wiki/EPEL [3] http://www.redhat.com/about/news/archive/2013/6/red-hat-software-collections-1.0-beta-now-available [4] http://lwn.net/Articles/552800/#Comments -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
