Ubuntu 14.04 comes with Python 3.4, but unfortunately, it doesn't bundle the ensurepip module (and a host of others). By the looks of things, the idea was to use Ubuntu's own packages instead[1], but it didn't make it in time.
This means that pip being bundled by default—one of Python 3.4 coolest features—is missing. Trying to create a virtualenv using the bundled virtualenv module fails as well. Big mess.[2]
For more information on how Debian, Fedora, and others are dealing with ensurepip see "Distributions wrestle with pip" at https://lwn.net/Articles/591421/
Except even then Python 3.4's bundled virtualenv module is still broken. The omission of the ensurepip module isn't an inconvenience, it breaks Python 3.4 functionality.
This is a real shame. Python 3.4 and bundled pip support was high on my list of reasons of why I should upgrade to 14.04 sooner rather than later. I think I'll wait now until this is smoothed out.
In the bug thread linked in above, it's mentioned that it will be fixed in Debian and then included in an SRU (Stable Release Update) for Ubuntu 14.04.
Does that mean July 24th or might it be earlier, do you know?
Better to stick to their bi-annual schedule, even if it means shipping a usable but not-quite-polished release, then polishing it in subsequent months. The previous versions, from 12.04 to 13.10, are more than adequate for anyone who can't risk upgrading to what is effectively a beta or release candidate.
The majority of 14.04 installations will actually occur after 14.10+ comes out, from corporations currently sitting on 12.04, who will take a few months to evaluate 14.04, and then, finally, upgrade to it. It will be stable by the time they do this.
Because these corporations behave this way, it excludes them from the set of people Canonical has to worry about pleasing at release. So LTS releases, right on release, are actually allowed to be less stable than non-LTS releases. Because the majority of their useful lifetime, when anyone that matters is actually running them, will be spent stable.
That is pretty fucked up. The point of declaring a release, rather than just shipping nightlies, is to let people know when it's ready. Having a dog's breakfast of a major release (which 12.04 certainly was out of the gate) substantially decreases my trust in Canonical.
Think of it like this--if they waited to ship the release until it was stable enough for corporations to use... then corporations would still take four months to evaluate it, so they'd only start using it was it was four months more stable than necessary. It's a bit like cooking a steak: if you wait for it to look medium-done in the pan, it'll actually be well-done by the time it hits the plate, because it'll keep cooking in its own hot juices after you take it off. You need to take it off when it looks medium-rare, if you want to serve it medium.
> Better to stick to their bi-annual schedule, even if it means shipping a usable but not-quite-polished release, then polishing it in subsequent months.
Better for whom? Not for the people who take the LTS moniker seriously, I think.
It is a problem, on one set of packages that are a part of a rather large distro, not sure I would consider it a show stopper, just an annoyance.
Yes, Python is a mess. But, Python has been a horrific mess for years now, on multiple distros. I just ended up giving up on Python. Distro problems, 2/3 split, GIL and various other buggy nonsense slowly just reduced its value versus other languages.
This isn't about Python being a mess, it is about an Ubuntu release messing it up. You know there's a problem when you lose important features you'd get with ./configure; make; make install