Hacker News Reader

Comment by alrs | Hacker News Reader

Mac-first development strikes again: pycage requires Python 3.5, which hasn't landed in Debian stable yet. Bummer.

I'd strongly suggest you contact the maintainer of the python3 package and request a backport. 3.5.1 is in testing, so it should be possible, and perhaps even easy to backport.

Tbh it might be as easy as recompiling it, Debian makes it very easy to recompile stuff, dpkg-buildpackage is trivial to run. Do it once on a throwaway image, keep the resulting package(s) forever - until new official ones land. This sort of approach can be a risk in production environments but for development images is fine and dandy.

I don't see the connection between the 2. I'm pretty sure MacOS only ships with Python 2...

Debian stable is a very very stable distribution, as such packages can be extremely outdated. He could compile or get it another way but that can be annoying.

It's par-for-the-course to "brew install" random stuff on a dev box. You lose a lot when you ditch distro-packaged Python and start relying on varying third-party schemes to drop something that may-or-may not be getting security updates and may-or-may-not have been compiled against the same libraries as the ones on your production system.

"It'll get there"

But seriously. If there's demand it'll get there. I've been using py3.5 on freebsd, openbsd and Archlinux for months. If enough software is written using the new hotness like Async, there will be pressure and motivation to get it packaged into stable.

I hope.

For people on RHEL, the IUS repository[0] guys do a great job.

[0] https://ius.io/

Python 3.5 will land in stable when Stretch becomes the new stable some time later this year, I'd be surprised if anyone went to work backporting with a new stable around the corner.

Or Ubuntu 16.04 LTS, Arch, OpenBSD, FreeBSD and many other places.

can you not use pyenv?

Not if you want to get security updates and run a binary that was compiled against the libraries on your system. If you start compiling Python yourself you need to start following mailing lists to keep up on security updates and running build servers to spit out your artifact, lest you put the entire gcc toolchain in to your production environment.

What about things installed via pip that are not part of the package manager, is that not the same thing as with pyenv? You could use debian's tooling or fpm to turn pip->dpkg but you still have the same problem of maintenance (which tbh isn't that big of a deal if you're developing, it's not a production env)

Also, I don't personally see what's wrong with having a compiler on production systems. Granted, if you don't need it and want to reduce bloat but treating it as a security hole is misguided imho. If the actor can't run gcc, then the could still upload their pre-compiled version, otherwise how would they get the source on to compile in the first place. Just seems a pointless measure

Reply on news.ycombinator.com