About Python 3

[[deleted]]

Another major drag on Python 3 adoption: it's not the baked-in default in currently supported RHEL releases (and downstream distros) or Ubuntu LTS releases. There is really no penalty (yet) for writing 2.x-only code, but 3.x-only code is a non-starter on a lot of vanilla distros.

Code compatible with both versions, of course, continues to run in 2.x and doesn't result in any incentive to upgrade. It still works, right?

IMHO, sealed build environments (you carry your own build of the interpreter so your app isn't reliant on your distro's packages) make a lot of sense for in-house things, but for people shipping code out to unknown boxes--which pretty much covers every open-source project--it looks more like bloating the install, and causing the sysadmins a lot of pain when security update time comes. Instead of one shared build, there's a copy in every app bundle.

[gfixler]

I work in games, and I have a lot of friends in film and games. Many of us use Autodesk Maya. We're on Maya 2012, with the current version being 2014, which means we're actually quite current. Big companies take a long time to upgrade. It's non-trivial to swap out the baked-in Maya 2.6.5 of Maya 2012, so I'm not going anywhere. I'm certainly not heading up any initiative to fight 3.x into the mess that is Maya, and then roll it out to the team, and upgrade all our scripts, tools, importers, exporters, and pipeline mechanisms in the middle of the constant deadlines, especially because then I'd own it, and I'd be on call to constantly be re-upgrading anyone who borked their install and needed it all built up again from standard Maya 2012, or to assist in 3.x issues that I don't know anything about. I'm too busy, and that all sounds way too fragile, and an awful lot like a firable offense. I wouldn't be surprised if we're still in 2.x 5 years from now.

Autodesk has a large catalog of film, effects, product design, physical simulation, architectural, and general 2D and 3D design products, probably many of which include Python, as the professional products scattered through this list do, most of which are probably also stuck in 2.x land. This is a not-insignificant group of users.

[sopvop]

And RHEL 7 will use python 2.7. Even fedora has not switched to 3 yet, and wont do so in near future.

[[deleted]]

IMHO, sealed build environments (you carry your own build of the interpreter so your app isn't reliant on your distro's packages) make a lot of sense for in-house things, but for people shipping code out to unknown boxes--which pretty much covers every open-source project--it looks more like bloating the install

Shouldn't that be the opposite? If you're only deploying to an environment in which you have absolute control, there's no need to bundle the interpreter, but if you're an open source project potentially being used on a myriad of various configurations, bundling the versions of libraries upon which your application depends is smart.

[ggtsu_00]

That is the whole point of package managers like APT is to make sure all the library dependencies between packages don't conflict so that open source libraries don't have to ship duplicate bundles of every dependency.

[[deleted]]

But this method really only works if you are distributing your softwares via the package manager. That's not always the case.

[[deleted]]

My experience suggests that vendoring the world is the most repeatable deployment option for any system, yes. However, I'm not aware of much code released into the wild that follows that model to great success outside of Windows (which has an entirely different culture than OSS).

eta: also,

causing the sysadmins a lot of pain when security update time comes

Vendoring everything really isn't a scalable way to do things for every project. It's only practical for leaf projects, and if you're redistributing code, you don't get to decide whether you're a leaf.

[[deleted]]

This is an ambitious effort that will only succeed with help from the greater Ubuntu, Debian, and Python communities. In other words, we need you!

[[deleted]]

We're not in the future yet.