python 3.7 on raspberry pi 3b+ and raspbian 9.4

I’ve been working again on the RPI 3B+, this time with Python. The current version of Raspbian, 9.4, comes stock with Python 3.5.4. I wanted the latest and greatest, so I decided to actually build Python 3.7 from source and install it locally to my account’s home directory. This leaves both versions of distro Python alone.

Note before you get started that it will take a good three hours to build and test Python 3.7 before you can even install it for use. The long build time is due to the extensive suite of tests the build process performs before it’s finished. You want all the tests to complete and to be successful.

You can follow my simple, dense directions, or you can go here:

Directions To Build And Install

  1. Install support tools to build python
    • sudo apt install libffi-dev libbz2-dev liblzma-dev libsqlite3-dev libncurses5-dev libgdbm-dev zlib1g-dev libreadline-dev libssl-dev tk-dev build-essential libncursesw5-dev libc6-dev openssl git
  2. Download the latest Python 3.x source from the GitHub source repository
  3. Untar the source into your account’s home directory from where it was downloaded
    • tar xvzf ~/Downloads/cpython-3.7.0.tar.gz
    • Note that the default download for Chromium is ~/Downloads unless you change it
    • Note that the current version as of the date of this post is 3.7.0
  4. Configure Python 3.7
    • cd ~/cpython-3.7.0
    • ./configure –prefix=$HOME/.local –enable-optimizations
    • Note the convention of installing into ~/.local
  5. Build CPython
    • make -j -l 4
    • make install
    • Note that make will take two to three hours. Just let it run.
    • Do NOT run as root; in other words, do NOT run with sudo
  6. Add CPython 3.7 to your path such that it is found first
    • Edit ~/.bashrc, and somewhere towards the bottom add:
      • export PATH=$HOME/.local/bin/:$PATH
  7. Open a new shell session and test that CPython 3.7 and pip3 are accessible
    • ‘which python3’ should produce /home/[login]/.local/bin/python3
    • ‘which pip3’ should produce /home/[login]/.local/bin/pip3

Once that’s all done, you can also check with ‘python3 –version’ or ‘pip3 –version’. CPython 3.7 should return ‘3.7.0’ and pip3 should return ‘pip 10.0.1…’ with additional information showing the filesystem location from where it was invoked, which should match ‘which pip3’.

Why Python, And Why Now?

First, this is a reaction to my less than pleasant experience with Julia 1.0. Not everything worked as claimed in Julia. I also discovered that the performance of Julia on a Raspberry Pi 3B+ with Raspbian is poor compared to Python. CPython 3.7 is blazing fast by comparison, especially starting up, and Python’s resource footprint seems a lot smaller than Julia’s.

Second, I have some programatic math work I want to do that Python does quite well compared to Google’s Go. Google’s Go is great for what I want it to do at the hardware level as I’ve documented elsewhere on this blog. But it doesn’t (yet) have some of the math support frameworks that Python has. Trying to make a single language do everything, especially some of the math work I want to perform, is a bit stupid when existing tools already exist and I know how to use them. All the important bits that I needed to run in Go I’ve already converted to Go, and I’m quite happy with. Python can pick up the rest.

Third, some of the example Raspberry Pi code for manipulating hardware is written in Python (2.7 to be exact). If it’s already running then it’s foolish not to use it.

Finally, it’s fun. I learned how to pull the latest Python and get it running on the latest Raspberry Pi, and while it took a while to get it build and have it self-test, the final results were worth it. Python 3.7 is very, very fast for a scripting language. And I like the fact it runs quite well on the Raspberry Pi, a feature it shares with Google Go.

surprise! django runs on arch linux arm on a rasperry pi 3 after all!


tl;dr: It was permissions issues that kept Django from executing properly on Arch ARM and the Raspberry Pi 3. Read on for the details.

Well, looks like I have to walk back that snide comment about Arch running on a Raspberry Pi 3. While I’m certainly no hero, I was irritated considerably by Django’s flagrant failure, enough to find out why. But first, some background.

  1. Django, along with a lot of other Python packages, is located in the system’s site-packages directory. On the RPi 3 running Arch ARM it’s /usr/lib/python3.5/site-packages. The site-packages directory is owned by root (root:root) with permissions 755. Permissions 755 means root can read/write, while group and the world can only read and execute from that directory.
  2. With that kind of ownership I had to install Django with ‘sudo pip install django’ (without the quotes, obviously). After installation every directory had 750 permissions, and every file had 640 permissions, with root:root ownership. That means, using the non-root account alarm, I had no permissions to read anything in the django installation.
  3. And thus any attempt to use django-admin was bound to fail

I don’t have copious amounts of time to work on these kinds of issues. So while I was out working on my honey-do list, while at Trader Joes in the organic produce section, the light went on as to what the probable problem and solution was. Sure enough, when I got home and found a minute to look, that’s when I found the permission settings all wrong. A quick ‘sudo find . -type d -exec chmod 755 {} \+’ and ‘sudo find . -type f -exec chmod 644{}\+’ fixed things up, and I was able to get a quick and dirty Django web server up and running. In fact, to test a capability I’ll need, I tarred up the sample I built on the MBP, secure copied it over to the RPi 3, untarred it there, and got it up and running. Here’s a couple of screen shots of it in action on the RPi 3:

Screen Shot 2016-08-14 at 2.46.50 PMScreen Shot 2016-08-14 at 2.48.01 PMLooks like I’m back in business. The only thing I edited on the RPi 3 was the polls/ with vi to change the text output by Other than that, I simply started it up.

This is the first time I’ve ever had a problem with permissions using pip and Python. In the future I’m going to have to be careful with Arch ARM. It’s a small issue, considering everything else works just fine.