My solution was to use pyinstaller[2] to basically ship my own python, first 2.7, and now 3.5.

[0] https://access.redhat.com/support/policy/updates/errata/#Lif...

[1] http://distrowatch.com/table.php?distribution=redhat

[2] http://www.pyinstaller.org

Then create a folder for your project, 'virtualenv -p /usr/bin/python3.5 venv' to create the venv in that directory. Activate/deactivate the environment as you wish when you want go between the system Python environment and the one in your folder.

I'm unsure how what I said:

> If you want another Python, then you need to install it yourself (somehow) and then point virtualenv at it.

Differs from what you are saying:

> 'virtualenv -p /usr/bin/python3.5 venv'

I know there's the argument that by straying you don't get security updates, but I can't really imagine Python 2.4 getting much security updates nowadays.

It's trivial when you have a handful of machines, all under your control. It's somewhat less trivial when you are dealing with 1000s of machines under the control of dozens of different people/departments.

I still use a few RHEL5 machines but nobody would ever dream of pushing new software to them.

Telling customers that they are doing things wrong isn't really a great way to win customers.

Why everyone is relying on python that's installed there for RedHat's needs (e.g. yum).

Unlike other languages, Python is probably the best one that can have multiple versions coexist together.

RHEL 5 is really common.

Environments where the build of your server is strictly controlled and conservative...banks, mission critical apps, that kinda thing where stability from upstream is hugely important.

To my mind, it's usually a good idea not to use system Python, both packages and the interpreter, if you're not also controlling them. This makes building your deployables more involved, but makes the actual deployment more painless.

How did the switch to Lua not break this in the same way?

Sorry for the naive question, I'm just not following how it can be possible to change languages, but impossible to change versions. At first glance, the latter seems like a special case of the former.

(EDIT: LUA->Lua)

2) Deployments with the new agent were noticeably faster, (like 1 second deployments that used to take 20+ seconds). However, this speed up was largely due to the Python codes design which had a "continuation" loop which was polling based, but the Lua code used coroutines and simply continued the threads when the steps were complete.

Overall, I think the choice to use Lua (or more specifically luvi) was a great decision. Note that it did take a few iterations in order to come up with the optimal way of using Lua + libuv. Originally I was taking the Node.JS approach of using callbacks, but that approach has two problems:

[a] It is difficult to properly implement "back pressure" so that all queues between producer and consumer are bounded.

[b] It is difficult to handle errors properly.

Lua coroutines allowed me to write a simple "green thread" library that encapsulated these challenges.

That was your problem, you just made a huge mistake and depending on how big your python code base was, you have now alienated most of your developers by moving to a language they are not already comfortable with.

Do your customers already have lua installed on their servers or are you bundling it now? You could have just a easily bundled a newer python interpreter. Lua is a nice scripting language, if you want to embed it into another app or to create a plugin system. It's not a nice general purpose scripting language, mostly because of the vast pypi repo.

The same thing could have been achieved within Python, but from an end user perspective I'm guessing this is an improvement for most of their customers.

The cost of effort their developers will have to put in to be as effective as a LUA developer as they were as a python developer is really not worth this move. There are more to moving to a different platform/language than just the end users.

Being as the size of the team is so dependent on a small number of high performers, I don't think it's unusual that they picked a language one of the main people in the company is extremely fluent in.

I've worked with Brian before and he is a beast. I don't know if 10x engineers exist, but if they do I would certainly consider him one.

I don't think what you say is completely true. People who are more experienced tend to be able to produce features much more quickly than those who are junior, just because they've already run into issues before so can anticipate them or solve them more quickly. If anything I would argue people like that actually write code more quickly that is more maintainable.

I don't know if he can ship 10x as many features; I didn't think term 10x engineer was used literally. I just know I've worked with quite a number of people and he is one of the best developers I know.

But then, we'd need to know how good your assessment skill/method is. Maybe you misjudge all the developers you work with? What feedback do you get?

@Chris2048 - Distelli is hiring. If you want to make your own assessment of my skill, then join us :).

Are you in a position to speak for Distelli developers?

"The cost of effort their developers will have to put in to be as effective as a LUA developer as they were as a python developer is really not worth this move."

I suppose this could be true in a poisonous environment where scheduling does not accommodate the need to learn a new skillset.

Unless you are familiar with the employer this is an incredibly hostile presumption. I.E. I would not work for such an employer nor would I want to be their customer

There will still be a minimum effort (e.g. in hours) that cannot be reduced by the nature of the employer. A dev will still have to put in the hours to learn a new language.

It seems the cost being described here is cost to the employer, not to the developer.

I also need to mention that Lua is the easiest language I've ever encountered, so any competent developer can learn it quickly, it's not alienating anyone.

Given that, I agree that LuaRocks isn't so vast as other languages' repositories and this can be a drawback of using Lua. But why again are you judging a language by it's package manager? If it's a good language wouldn't it be better to suggest more people to write packages instead of suggesting people not to use it?

I read it more as "relying on a runtime that must be installed on the user's OS instead of included in our executable is a nightmare". The dramatically reduced conceptual footprint of the language is a nice bonus though.

* Some companies have absolutely no in-house tech staff to speak of, and so they want to invest in technology exactly once and never have to deal with it again.

* Some companies have in-house tech people, but are entirely marketing/sales driven with little or no input from the tech staff. So they focus exclusively on writing new features and never clean up technical debt.

* Some companies choose a platform to bet the farm on, develop a huge amount of in-house code for it, and then realize that since they wrote it for specifically the exact version of the platform they first installed, any upgrade involves a complete refactor/rewrite, which they then dismiss as too expensive.

The first case can be solved somewhat by subscription-model managed services where the upgrades just happen at the discretion of whoever's managing the platform.

The other two are failures of management and planning, and absolutely should be laid to rest at the feet of the management staff involved. Preferably in an expensive way, pour encourager les autres.

What companies often learn too late is that there are basically two options:

1. Make maintenance -- both in terms of upgrading underlying software, and addressing accumulated technical debt -- a regular, required part of their process, or

2. Occasionally face a potential existential threat from the unbounded cost of staying fixed in perpetuity to a stack that "already worked" once upon a time but no longer does due to lack of upstream support and available developers to keep it limping along.

The genuine problem is that "what does this do for next quarter's results" is the only concern, which means long-term thinking is actively discouraged.

python35 will be soon be coming to EPEL also.

RHEL4 = Python 2.4 RHEL5 = Python 2.5 RHEL6 = Python 2.6 RHEL7 = Python 2.7

netifaces: ...would require me to build a C extension which would mean going down the rabbit hole of building and bundling python and this library.

Why? What's wrong with 2.7?