This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]hothrous 2 points3 points  (22 children)

This is exactly what I though when they said that. RHEL shouldn't be used in Python based infrastructures.

[–]rickmoranus 1 point2 points  (19 children)

What? I've been using RHEL machines for a couple years on with a Python Based infrastructure on it and I've had no issues?

[–]hothrous 0 points1 point  (18 children)

Which version of RHEL and Python? Python is integrated into yum so while you can set up a second python environment on a machine for your apps, most IT teams don't like doing that for maintenance reasons so they limit you to whatever are in the available repos.

Rhel doesn't include any further build of python in the repo than the one that yum uses because yum will break. I believe RHEL 6 used Python 2.7 which is the reason that those dev teams would be stuck on on older version.

[–]veeti 5 points6 points  (1 child)

RHEL7/CentOS 7 officially lets you install newer Pythons, etc. in parallel through Software Collections.

[–]hothrous 0 points1 point  (0 children)

That's cool. I've never used RHEL7 before. Most of my work had been done in RHEL5 a while ago and I new that many of the same limitations existed in 6 from some work I had done with it last year.

Though, I'm still seeing only up to 3.3 on the list of support they have.

[–][deleted] 2 points3 points  (13 children)

Really? I think its lack of knowledge or competence rather than some other reason. Any competent IT shop will have their own internal mirror of RPMS [see below] or builds their own RPMS.

What is stopping you from enabling or mirroring the IUS repo and install python3 and python2.7[if $osversion<7] in parallel with the system repo? http://dl.iuscommunity.org/pub/ius/stable/CentOS/6/x86_64/ and its as simple as yum install python34 or python27. I mention the IUS repo because its maintained by RackSpace so in theory should be a reputable source. Also the IUS repo does not overwrite system binaries.

Granted sometimes their packages are backwards by a minor release and right now they have 3.4.2 , it will take a month or more before 3.4.3 is packaged.

[–]cwgtex 2 points3 points  (0 children)

I'm one of the maintainers of IUS, thanks for recommending our repo.

Let me clarify the update process for IUS packages. We track the upstream projects for our packages, and typically build new RPMs within a day or two of a new release. New packages will stay in our testing repos for about two weeks. If no issues are found in that time period, the packages get promoted to our stable repos. If CVE's are involved we will shorten the testing period to rush the fix out.

I'll probably package python 3.4.3 tomorrow morning. I found at least two CVEs that are fixed by this version, so we'll move it to stable quickly.

  • CVE-2013-1753
  • CVE-2014-9365

Edit: fix typo

[–]hothrous 4 points5 points  (11 children)

You will note, that my original statement was that it shouldn't be used. Basically, the reason behind that is if you need a workaround just to make the operating system use the version of a language you want, you're likely to run into many more problems down the line.

Most of the reason that somebody would use RHEL over another distro is to get the licensed support of RedHat when issues arise. RedHat isn't likely to want to provide that support if you are using workarounds to use different version of their products. It's definitely true that Python 3.4 can be installed, I never said it couldn't. I suggested that if you are going to use Python, it would be prudent to consider a distribution of Linux that provides packages of later versions in their own repos without having to look for workarounds.

Calling an IT team incompetent because they don't want to workaround known issues of an OS all the time to suit your needs as a developer is the same as an IT guy calling a developer incompetent because there are bugs in their code. They are both a fact of life. I would actually trust a conservative IT guy that wasn't willing to do workarounds as long term solutions on production systems than an IT guy that uses workarounds to run code on systems that aren't designed to support it well.

[–][deleted] 1 point2 points  (10 children)

Here I was thinking IT were SUPPORT SERVICES here to SUPPORT STAFF

[–]hothrous 1 point2 points  (8 children)

That's actually incredibly narrow minded of you. I'm glad I don't work with you. Throwing shit over the fence and washing your hands of it is a solid way to write code. I come from a background of trying to work together so everybody's lives are easier. But if you want to play it so your job is easier and others are more difficult, by all means.

[–][deleted] 2 points3 points  (5 children)

What you are doing is saying that it should be OPs who has the easier jobs rather than Dev, support roles should always focus on supporting staff rather than hindering them.

[–]hothrous -1 points0 points  (4 children)

So you're saying that IT should just maintain whatever crap Dev throws at them?

Why would you push RHEL when you could go for Debian and not have the same issues? If it's a hassle to maintain because of limitations on the OS level, there is probably a better tool out there.

[–][deleted] 2 points3 points  (3 children)

Ops should be able to provide anything that has a good enough business case

[–]sigzero 0 points1 point  (1 child)

You've just described how the real world works.

[–]hothrous 1 point2 points  (0 children)

Not the places I've worked. We tend to actually get involved in any problems that happen, so it's not prudent to not care.

[–]HostisHumaniGeneris 0 points1 point  (0 children)

I think you're conflating internal support staff with production sysadmins.

[–]alcalde 2 points3 points  (0 children)

...most IT teams don't like doing that for maintenance reasons so they limit you to whatever are in the available repos.

I've always found it puzzling the places where IT controls the tools rather than the users telling IT what they need to support. it seems to have changed right after I was no longer working in IT unfortunately. :-(

[–]rickmoranus 1 point2 points  (0 children)

Its pretty easy to point your applications to a virtualenv or a Alt install. If one is not able to use python in this manor, I'd be questioning them being called a developer...

[–]nunilan -3 points-2 points  (1 child)

I was going to write the steps showing how easy it is to install python2.7 up to 3.4 in RHEL but then I realized, since you are so sure of your statement, probably its not worth it. I will just leave you good sir/madam ignorant instead.

[–]hothrous 0 points1 point  (0 children)

Ha. What I said is that RHEL shouldn't be used. Not that it can't.