5 ms·

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

by alrs 10y ago

sandGorgon 10y ago
can you not use pyenv?
- alrs 10y ago
  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.
  - _joel 10y ago
    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
dijit 10y ago
"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/ https://ius.io/
- alrs 10y ago
  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.
oblio 10y ago
I don't see the connection between the 2. I'm pretty sure MacOS only ships with Python 2...
- vopi181 10y ago
  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.
- alrs 10y ago
  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.
adamrt 10y ago
Or Ubuntu 16.04 LTS, Arch, OpenBSD, FreeBSD and many other places.
artlogic 10y ago
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.
- toyg 10y ago
  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.

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

by alrs 10y ago

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

sandGorgon 10y ago

can you not use pyenv?

alrs 10y ago
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.
- _joel 10y ago
  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

dijit 10y ago

"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/ https://ius.io/

alrs 10y ago
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.

oblio 10y ago

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

vopi181 10y ago
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.
alrs 10y ago
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.

adamrt 10y ago

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

artlogic 10y ago

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.

toyg 10y ago
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.