News for hackers. Stuff that matters.
Re:Python Wheels by coherentpony on Monday August 03, 2015 @07:11PM (#10000517)
As a casual python user, I've always found it fairly straightforward.

As a systems engineer, I've always found it challenging to maintain a sane python ecosystem across multiple hosts.

Re:Python Wheels by e12e on Monday August 03, 2015 @10:02PM (#10001226)
As a (now casual) sysadmin, I think things have gotten a bit better. Virtualenv (now part of python3) helps a lot. The trick, if running on Debian, is:

1) use system python -- if you can. Now with python3.4 and 2.7 in stable, that's the easy bit.

2) If you can't do 1), use backports and/or manually backport[1]

3) If you need python-packages that depend on c-libraries, use "apt-get build-dep python-foo".

4) use a virtualenv, or several virtualenvs, eg:

  virtualenv -p python2.7 myvenv
  ./myvenv/bin/pip list -o #list outdated packages,
   # typically that'll mean you first need to:
  ./myvenv/bin/pip install -U pip #possibly also setuptools
Then install the packages you need with pip -- see 3) for tip on stuff like pyqt that needs some (fairly hairy) packages.

This works for most everything -- except perhaps for pygame, which is exceptionally gnarly.

[1] Manually backport, the easy way:

  sudo -s
  echo "deb-src http://httpredir.debian.org/debian\
   sid main contrib non-free" \
   >> /etc/apt/sources.list.d/sid-src.list
  apt-get update
  cd /tmp
  apt-get build-dep python3
  exit # No need to build as root
  apt-get source python3 # this assumes sid has a version
   # that'll work for you
  cd python3*
  dpkg-buildpackage -uc -us
  cd ..
  sudo dpkg -i python...deb
Note, this may or may not work with major packages like python -- but it often goes a long way. If you can't get enough build-deps satisfied, things are more complicated -- and you're probably better off running testing/unstable in a chroot, possible with help of the schroot package -- rather than fighting with conflicting packages.
Re:Python Wheels by dvanduzer on Monday August 03, 2015 @07:27PM (#10000593)
The Python ecosystem is so good about portability, but flexibility always comes with a cost.

I'm assuming your systems engineer perspective is colored by RedHat (and others) packaging python-ldap at the system level and then leaving you to your own devices for everything else.

C bindings are really convenient, but then you have to worry about dynamic linking. Are you sure Python is linked to the same OpenLDAP library that NSS uses? Hence, system versions of some Python packages, but only where other system level dependencies are an issue.