Hacker News Reader

Comment by falcolas | Hacker News Reader

I'm sure it is. Still doesn't address reasons I can't migrate to 3.3, though (those being CentOS6 defaults, lack of packages, cost/benefit ratio too high for migrating).

View on HN

> CentOS6 defaults

I've always considered it bad to use the RH provided python for development.

> I've always considered it bad to use the RH provided python for development.

May I ask why?

I see why maybe using your own compiled 2.7 or 3 might be nice, I don't, I just use the one that comes in with CentOS/RHEL 6.

* It get regular security updates from upstream

* Easy to install, it is part of existing package dependency chain (as opposed to say doing make ; make install from source)

* It comes with a default repo

* Most Python packages today are compatible with 2.6

> May I ask why?

Independence. When you upgrade to RH7, you don't need to worry if all your scripts will run with Python 2.7, they'll still point to your own 2.6. You can decide to upgrade to 2.7 (or not) on your own time. You can do it before or after your migration to RH7; they're independent decisions. Even ignoring Python3, Python occasionally breaks backwards compatibility (the deprecate, warnings, then errors dance). It's nice to control your own situation.

But our programs are internal-use only. So we don't have the same concerns with security updates, ease of deployment to customers, etc., that you may face.

At the facility I work at we're still migrating from Cent5 to Cent6. Cent5 is installed with Python 2.4 (released 2004-11-30, unsupported since 2008-12-19). Thankfully, we're juggling Python 2.5 and 2.6. We rely on a couple pieces of third-party software that include their own Python (2.6 and 2.7).

But even without the third-party software I'd prefer to use a separate install of Python. If there were a few Python scripts there and there, we could probably manage, but managing a large Python codebase would be ridiculous trying to rely on the OS version of Python. Transitions to new OS versions would be way harder, too.

> > I've always considered it bad to use the RH provided python for development.

> May I ask why?

A great deal of the Red Hat management tools use that Python, so it's not something I advocate altering beyond the python packages provided by RHEL/CentOS/Scientific Linux.

Yes I can use virtualenv, but by the time I'm going that far, especially in the event of deploying 100's to 1000's of hosts, having a separate installation just isn't so difficult.

True, but are there any decent repos for installing python3? Even with 2.7 I generally have to build it myself. I loathe having to use RH5 and RH6 due to how old they seem.

Edit:

Python 3 may see more adoption if they provided .rpms and .debs directly. When you have to install python on 100s or 1000s of machines, doing them one by one is simply impractical.

I haven't been able to find any good repo (recent, maintained, reputable maintainer) unfortunately. I usually end up compiling them myself. I was actually surprised how easy it is, nevertheless a (possibly official) repo would be _very_ nice.

Fedora has the ability to install python3 alongside the system python2.7, so there is probably an official rpm you can just pull from the Fedora repos.

edit: https://admin.fedoraproject.org/pkgdb/acls/name/python3

By the time you're looking at deploying to hundreds or thousands of hosts, it seems that you would be creating and controlling your own repo's. Thankfully building Python is straight forward, so building a rpm shouldn't be too painful.

Though it did seem odd that there wasn't already a repo for Python 3, so a little googling found this -

http://iuscommunity.org/pages/About.html

Reply on news.ycombinator.com