Hacker News Reader

Comment by beaumartinez | Hacker News Reader

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]

[1] https://launchpad.net/ubuntu/+source/python3.4/3.4.0-2ubuntu...

[2] https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/129...

View on HN

For more information on how Debian, Fedora, and others are dealing with ensurepip see "Distributions wrestle with pip" at https://lwn.net/Articles/591421/

Yes, you still have to apt-get install python3-pip, just like older releases. This doesn't sound like the worst thing in the world though.

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.

Ubuntu 14.04.1 is scheduled for July 24th.

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?

The point release is a roll up of the previous fixes, so if the bug is fixed beforehand you'll get it in an update.

Oh, excellent. Thanks very much for the reply.

How did they ship this? It's clearly an unfinished release.

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.

From LTS I'd expect something more than not-quite-polished. Maybe polished-a-bit or slightly-polished.

Customer: "It doesn't work!"

Project manager: "But hey, we shipped on time!"

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.

It's absurd.

Late adopters wait because they'd like somebody else to flush out the early bugs. If this is actually Canonical's plans, that 14.04.1 is the first release expected to be stable, then if I were a late adopter, I'd just wait for 14.04.2.

The let's-trick-people-into-adopting-something bit is basically an attitude of customer contempt. It's assuming that the release knows the customer's business better than the customer does. Whether it's right or wrong, it's a dick move, and acts to decrease trust.

I'm sure that the vendor will gladly return the money paid for it.

You mean after the project manager has switched projects and management has voted itself a bonus ?

Absolutely.

The argument for rolling release in a nutshell.

I prefer the "we bottle no wine before its time" model. It's one of the many reasons I prefer EL distributions to Ubuntu.

14.04 is an LTS version of ubuntu though.

... which unfortunately means you're stuck with whatever's broken.

Sorry, i misunderstood your comment - i read "EL distributions of ubuntu" and thought you were using EL to mean LTS.

Not necessarily. It can be fixed in point releases. This has happened before.

I've only seen bug fixes in LTS releases, not changes in functionality that would address significant issues (at least under 10.04 and 12.04). Any significant change would be in a point release (e.g. 14.10) which is not LTS - so you can't have your cake and eat it too under this model.

> 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.

Their bi-annual schedule is why Ubuntu has a reputation for releasing buggy, user-unfriendly software.

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

Reply on news.ycombinator.com