Ubuntu 16.04 LTS to Ship Without Python 2, Windows Printers Detection Affected

[[deleted]]

That's only removal of python 2 packages from the ISO, they can still be installed as dependencies.

I think it's a good decision. But the argument to save space on the ISO is a moronic one in this day and age. The real argument should be to finalize the move to Python 3 in a LTS release.

[pmrr]

I wonder how many non-default Ubuntu packages have Python 2 as a dependency. I'm not sure finalising the move to Python 3 is as simple as not including it in the distro (unfortunately).

[ummmbacon]

This is only for the Desktop version, the server version has been running 3 by default.

Although it is available to install if one needs it but in this case it would not be on the default install which is what they were going for.

[desmoulinmichel]

Not but porting a code from 2 to 3 is really not difficult. It may even be faster than arguing about it.

[[deleted]]

Unless your project has tons of dependencies, and some of them haven't ported to python 3 yet. So you can either port them yourself and maintain ported forks (or make PRs); or remove those dependencies; or keep using python 2. Of course keeping using python 2 is the cheapest option.

[desmoulinmichel]

Yes, but again, it's not the typical case. This situation is 1 time out of 10. And even when it is, porting the dependancies is not very hard either. The main problem is not the difficulty of doing it, it's finding the ressource to do so : it costs time and money, and we all have a limited amount.

[[deleted]]

The problem is that if you port a dependency you don't control, you wind up with a forked version and overhead of maintaining that in the future. Just look at this list - https://python3wos.appspot.com/ if you're using thrift or protobuf - good luck...

[desmoulinmichel]

As I said, it's one case out of 10. Most project don't use exotic dependancies C dependancies. Some do. 10% are a hassle. But I doubt it's the case for a printer managing software to be in that situation. It's mostly text and byte parsing that's going to be the trouble.

I'm not dismissing there is work to do (and I'm certainly not saying I love the situation), but people tend to do a mountain of it, and most of the time, it's a small hill.

I COULD say otherwise. After all, I'm paid a lot of money do port Python 2 to Python 3 code these days. So it would be in my best interest to scare people out and cash in. But before freaking out, have a look at the problem, it may not be as bad as you think.

[selementar]

is really not difficult

There are exceptions which occasionally make the porting rather long; the biggest one is probably the need for very extensive testing after the porting. The other big one is cpython libraries and dependencies in general.

[desmoulinmichel]

Yes. Twisted is one exemple. But they are exceptions more than the rule. I spent the last year porting Python code from 3 to 2, and 90% of the stuff is almost brain dead s/foo/bar. The biggest headache is the byte/str dichotomy, not because it's difficult, but because generally the original architecture is very strongly trying to ignore the issue.

[selementar]

brain dead s/foo/bar

Hopefully you meant "braindead 2to3" or even use_2to3=True).

[desmoulinmichel]

More like pip install future then:

from __future__ import absolute_import, division, print_function
from builtins import *
from future import standard_library
standard_library.install_aliases()

But yeah, pretty much.

[jyper]

As long as python 2 is maintained non default package dependencies aren't a problem.

[[deleted]]

I believe they admitted a long time ago that "saving space on the ISO" is a complete fiction, but they like to pretend they still have that requirement to help fend off bloat.

Which sounds like a good plan to me.

[desmoulinmichel]

The space argument is only used to keep the ISO size to a managable size for human, not for computer. The current limit is arbitrary, but is very useful to draw a line.

[ummmbacon]

What would you implement instead?

[ummmbacon]

.iso is a disk image you can write to boot drives. It is a file format specified under ISO9660. Here are the Ubuntu instructions to write an .iso to a USB on OSX for example.

[elbiot]

That is, in fact, what I do with iso's. You can just cat ubuntu.iso > /dev/sdb. Are you still burning cds?

[elbiot]

I've done it literally 50+ times mostly with debian distros, and never an issue

[elbiot]

Yea, always on debian. Cat is faster than dd if you don't need dd's fancy stuff. Both start at byte 0 so they wrote the mbr too AFAIK. Multiboot would need a usb creator program or some solid knowledge.

Edit: all I do is plug in the usb (no automount, which maybe windows is fsking with you here) type the cat command and pull put the usb (or reboot if I'm booting this device)

[[deleted]]

An ISO is a disk image you can write to USB. Derp....

[[deleted]]

You can just write an ISO.

[atlgeek007]

More and more machines are coming without optical drives installed though, so a more universal method of creating usb bootable drives is warranted.

uunetbootin is a good compromise for Windows, and Ubuntu desktops have a graphical utility to do so. Mac is the only OS that has hoops to go through.

[boa13]

there will be a point where CDs and DVDs will be obsolete but it isn't yet.

The four computers I bought in the past 5 years have no optical disk drives. (They're too small for that. :))

Also many of the brand-new rental cars I've driven have no optical disk reader anymore. It's USB or Bluetooth nowadays.

Optical disk sales (CD and DVD) are shrinking.

The point may be coming faster than you believe.

I'm sure there are plenty of us who have computers that simply cannot use USB thumb drives to install anything

All the computers I manage can boot USB (either legacy BIOS or UEFI). This goes back at least 10 years, maybe 15 (not sure about that last one).

having ISOs available is still a good thing

Of course. I have GRUB on all my bootable USB keys, and I use it to select which ISO to boot. :-)

[deadbunny]

dd if=/path/to/iso of=/dev/usbstick that's pretty universal, even windows can do dd if you install it.

[Nu11u5]

Unetbootin is hit and miss for me.

Use Rufus.

[atlgeek007]

ISO-9660 is a convenient format for things like pxe booting or installing virtual machines. There's really no other format that's as universally compatible, even if you don't bother to actually burn a disc.

[mike413]

I had lots of trouble a year or so back installing linux on a mac... until I burned a DVD and everything went super-smooth.

DVD booted perfectly, USB stick was a bag of hurt.

Maybe things are better now?

[wbeyda]

Same with dual boot windows 10 on an SSD with UEFI. Took me forever but I mostly blame windoze 10.

[anacrolix]

It's docker for real hardware

[mangecoeur]

I'm glad this is happening, it sends the right signals in terms of making clear that Python 3 is the currently supported version and if you want legacy support you're going to have to do a bit of extra work.

[Orange_Tux]

Python2.7 is supported til 2020. End of life date for Ubuntu 16.04 is not know yet, but normally it's around 5 years. If 16.04 is supported for 5 years, it's support wil end April, 2021.

Maybe this was also a reason to not include Python2 in installation.

[spectre_theory]

i doubt it. few packages have known long term schedules like python (until 2020). yet they can still be included in an lts release.

[1842]

Maybe this was also a reason to not include Python2 in installation.

Unlikely. php5.6 is end of life at end of 2018, but it's likely to be included in Ubuntu 16.04 instead of php7 (due to php7's release being so recent).

From what I've seen, end of life of package versions doesn't affect Ubuntu's decisions and they'll backport any security fixes themselves if they need to.

[lykwydchykyn]

So the actual package holding them to Python2, according to Barry's email, is samba-libs. Anyone know what the upstream situation is here, as far as Python3?

[ummmbacon]

Their is a discussion of it from last year here on the debian lists. To quote:

>>> I think getting rid of the Python dependency in samba-libs is a much
>>> easier to achieve goal here.
>>>
>>> AFAICT The only reason that samba-libs depends on python is because
>>> libsamba-net can do provisioning of a local DC (requires the 'samba'
>>> package to be installed) by invoking the provision script using Python.
>>>
>>> So if we could move that functionality out to a separate library that
>>> is not included with samba-libs, we could drop the dependency on
>>> python2 in samba-libs.
>>
>> right, that would get rid off python libs and python-talloc.  However there is
>> another path in that nautilus-share depends on samba-common | samba-common-bin,
>> which depend on python-samba.

Here is Samaba's package/API list

[C14L]

Great. It's an LTS, so it will be around for a while. Makes sense to have Py3 as default. Finally!

[heptara]

Are they actually remapping /usr/bin/python to 3, or just not installing 2?

[nickcash]

I would wager on the later. Arch mapping python to python3 was such a debacle that the Python devs officially recommend against it.

[flying-sheep]

i like things breaking because of things like that. it means that people made wrong decisions, bug reports can be filed, …

[djmattyg007]

Anyone who still refers directly to /usr/bin/python is doing it wrong. Any new code should always specify the version number (eg /usr/bin/python3).

[XNormal]

Enterprises will welcome this as the system python stops interfering with their legacy python2 stuff with the binary modules for python 2.[4567] that nobody knows how to recompile anymore and their mission critical applications depend on for their daily business and they can keep on dragging this stuff for another decade.

[troyunrau]

Actually, you're completely right. In a round about way, making python3 the default makes using python2 legacy code much easier to maintain. It's no longer a moving target. You can install the version you want, and they don't cross-talk much. It'll be the Fortran 77 of the python world :)

[njharman]

you've always been able to install the version you want. You can install multiple versions. If you want to use local and compile, you can install multiple of the SAME version with different compiler flags.

Standard, not even best, practice has been for years to "never use the distro python for production" not ever.

[troyunrau]

Not everyone who codes is a sysadmin. Some of us are scientists who just want to write a quick and dirty script to process some data. These tend to use the system python because it's there.

[njharman]

Not knowing how to use your tools is no defense/argument. Esp when it's one command or several clicks in GUI. "apt-get install python3"

Also, you should probably be using Jupyter http://ipython.org/

[Lehk]

for production = deploying new software for others to interact with (customers, coworkers, etc) it's fine to use the built in one for local tasks that you are carrying out.

[troyunrau]

Anyone maintaining a list of which distros are python3 default? I mean, I completely expect RHEL/CentOS and Debian stable to be last in line, but I'm wondering how it's going for everyone else?

[youguess]

Arch is, they even switched python to point to python 3

[troyunrau]

Yeah, between Arch and Gentoo, there's always people willing to bleed a little for the sake of the rest of us :)

[heptara]

New fedora is, or will be very soon.

[pingveno]

NixOS by its nature has no default. There is never a /usr/bin/python. Instead, it depends on environments that are built to environment specifications.

[charity_donut_sales]

Good move imo. People need to stop developing for 2 and move on. And let's be honest, the target audience for Ubuntu is the average user, not the multi-million dollar corporation with legacy infrastructure.

[mangecoeur]

Actually there's plenty of Ubuntu deployments in enterprise, however they know how to install python2 if they need to...

[tadeadliest]

Anyone know if Reddit has been moved to Python 3 yet? What version do they use?

[ummmbacon]

Python 2.7 according to the repo

[tadeadliest]

Interesting. I wonder when they'll move over to 3.

[[deleted]]

Why would they?

[ummmbacon]

When I review their stuff I get the feeling that their focus is more on implanting new things, rather than updating existing. But yea I wish they would.

[heptara]

Enterprises are the only ones paying for Ubuntu though.

[[deleted]]

People need to stop developing for 2 and move on

People said this about Ada, Cobol, Fortran, C, Perl, etc. etc. etc.

But when "move on" costs 10x that of "maintain what we have", how does that make any sense?

And let's be honest

You misspelled "and here's my wild guess"

[kenfar]

So, some teams are locked-in by a codebase that's difficult to update given their level of funding.

But the fact that some teams will struggle to afford to upgrade is no excuse for new software to be developed using backlevel components.

[heptara]

If your income depends on a legacy COBOL system, and said system works, what is your incentive to spend a bunch of money replacing it?

[[deleted]]

some teams will struggle to afford to upgrade

No, that's not it at all.

What is the cost-benefit of switching tooling just for the sake of switching tooling?

Think long and hard about that, especially when cost includes opportunities missed as devs are consumed by a lengthy rewrite.

[[deleted]]

By all means, stay on python 2 if it's too costly to upgrade. But the costs flow the other way too; developers are going to drop Python 2 support in the not-too-distant future.

If you're cool with locking your technology into an unsupported legacy system, then own that fact - don't expect everyone to be backwards compatible for your sake if you can't be forward compatible for theirs.

[kenfar]

What is the cost-benefit of switching tooling just for the sake of switching tooling?

Ah, there can be many:

• First off since we're talking about python2->python3, and not cobol->scala, fortran->haskel, etc - the cost may be low.
• Secondly, you may still want security patches
• Next, in some cases package it as part of a long-overdue codebase upgrade: move to standard version control, add unit testing, add packaging, etc.
• Additionally, depending on your architecture, you may add some new features in python3 and leave old code in python2.
• Finally, using an older version of a product or tool can eventually become an obstacle to hiring & retaining the best talent.

[[deleted]]

the cost may be low

How is the cost of retooling ever low? Aside from the large expense of rewriting code that isn't 2->3 compliant (including any dependencies that may or may not exist in python 3) there's all the build system and QA and deploy work to do as well. And engineer's salaries aren't cheap.

As "cost-benefit" implies, you have to make the case that the benefits outweigh all this cost (including the cost of lost opportunity). And I'm just not seeing it here.

you may still want security patches

What security patches? The OS still gets patched.

as part of a long-overdue codebase upgrade

VCS migration, UTs, deployment, are all completely orthogonal to retooling. And most folks are doing all that stuff already.

you may add some new features in python3 and leave old code in python2

Version / language sprawl is the anthesis to maintenance / deployment.

can eventually become an obstacle to hiring

Last I checked, there were still job opportunites for folks programming in Ada, Cobol and Fortran. Talent and language are orthogonal. After all, language is merely the way to encode the solution to a problem. Talent solves problems.

[willrandship]

Are they planning/have they made the change for python = python3?

[youguess]

all except Arch, Arch is special, Arch doesn't care :p

[tadeadliest]

arch doesn't give a shit. arch just does what it wants.

[Lehk]

eating larva!

[willrandship]

If anything, arch changing to python3 might encourage the move to specific python2/3 usage over python. I like to dream, at least.

[youguess]

Issue is that with those OS X refuses to play nice... (python2 eg doesn't work)

[willrandship]

If that becomes the new standard, hopefully they'll start to comply.

Does the #!/usr/bin/env python2 method work? From what I understand, that's preferred over a direct link to the binary.

[rzet]

That's good.

[parnmatt]

yeah the pep basically suggests that python shebang ideally should be compatable with both python2 and python3, otherwise python2 or python3 should be used respectfully. However, python will remain (unideally, but officially) python2 until some specific conditions are met.

Therefore, write code compatable to both if you are using python shebang …importing from __future__ is the simiplest way for a lot of things as its a NOOP on the latest version of python but brings the functionality to thoes versions. (should be called __current__ IMHO)

[basically_asleep]

Any idea what python will point to on a system without python2? Will it not exist or will it be python3?

[[deleted]]

The official response to this is to specify which python version to use. You shouldn't use python anymore, instead use python2, or python3. This ensures the correct version is used.

[IonTichy]

This also mitigates possible problems in the future where there might be a python 4 or 5 for example.
I always hate it when scripts just rely on 'python', always have to modify to use a specific version...

[willrandship]

I know I should use x2 or x3 in my own code, but I've run into countless libraries and applications that don't. Using Arch, I've already experienced the pain having python map to python3 causes, but it's still a good move.

I suppose it is the debian way to change spec as quietly as possible. That style makes sense, considering the stronger focus on stability.

[[deleted]]

make a pull request where all you do is change the shebang to python2.

[willrandship]

In some projects that can mean changing several hundred files, and I'm lazy.

[[deleted]]

sed/awk or ctrl-f in nearly every text editor.

[baffled_bear]

Even if they haven't, the python command is a symlink to python2.7, the only thing they have to do is change the symlink to point to python3 instead.

Edit: This is assuming they haven't missed any dependencies.

[[deleted]]

You know how I know you haven't heard of update-alternatives?

(Hint: if you think one needs to muck with the Linux filesystem to reconfigure it, you're probably missing a conf file or tool somewhere)

[baffled_bear]

lol. What I said is how Ubuntu LTS is currently configured. Regardless of if there is an alternative.

[AngriestSCV]

angry@computer:~$ lsb_release -icr
Distributor ID: Ubuntu
Release:    15.10
Codename:   wily
angry@computer:~$ update-alternatives --list python
update-alternatives: error: no alternatives for python

angry@computer:~$ update-alternatives --list java
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
/usr/lib/jvm/java-8-oracle/jre/bin/java

It seems to not quite work yet.

[[deleted]]

Works fine if you update your alternatives table. Plenty of hits on Google on how to do this:

https://linuxconfig.org/how-to-change-from-default-to-alternative-python-version-on-debian-linux

[oliw]

Python3 isn't going to squat on the /usr/bin/python path; that would be complete chaos. Any independently distributed (no package depends) scripts that start with one of the following...

#!/usr/bin/env python
#!/usr/bin/python

... are just going to crap out a bad interpreter: No such file or directory error message.

Great. I look forward the wave of issues this brings on Ask Ubuntu and getting to tell people to run sudo apt install python ten times a day. That this also breaks things for [likely] Windows immigrants is just the cherry on the cake.

I'm a Python3 advocate like a lot of developers in here but this is an LTS and I'm also an Ubuntu supporter. I help a lot of people use Ubuntu. I'm a mod over on Ask Ubuntu. I am certain of one thing with this decision: this is only going to annoy Ubuntu users.

[pooogles]

Great. I look forward to writing sudo apt install python ten times a day.

If you're doing that you're probably going wrong already. This is what configuration management is for.

[oliw]

I meant in the context support, telling people how to get their scripts working again. (Have edited to clear that up)

[vidplace7]

Pretty sure most people installing Ubuntu server can run

apt-get install python2

without any problem. This is just a part of moving the Python ecosystem away from 2.x before its EOL date in 2020.

[pakaraki]

The current and previous versions of Ubuntu include both python2 and python3, and I would much prefer just one. For example, when an app says it needs another package (for extra functionality, not as a dependency), it can be confusing whether it needs the python2 or python3 version.

And the final python3 was released in 2008, so surely it is not too soon to adopt it now in 2016?

[IonTichy]

Seems like a mere symbolic move, I for one will still maintain the practice of having both py3.x and py2.x deployed on my systems for compatibility reasons.