This post is an unorganised collection of notes about how I use Python effectively on OS X. Disclaimer: I don’t pretend to be a Python expert, by a far mesure, so there could be some Pythonic horrors in this article; if you think so, just drop us a mail, and we’ll update this article.
TL&DR: don’t use the pre-installed OS X Python. Use Python with Homebrew. Never ever sudo pip. Use virtualenv / virtualenvwrapper. PyCharm worth the price. Python rocks.
- OS X default Python installation
- Installing brew
- Installing Python 2.7 with brew
- Installing third-party libraries
- Shell scripts with Python
- Must-have packages
- Python 3
- IDEs on OS X
- Various tools
1. OS X default Python installation
A quick word about the default Python installation. Python comes pre-installed on OS X. If you open a terminal, and simply ask for the location of the python binary, you will see:
$ which python
/usr/bin/python
Launching the interpreter in a terminal window:
$ python
Python 2.7.5 (default, Mar 9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
So Python 2.7.5 is the default python interpreter. If you need to, Python 2.6.8 and Python 2.5.6 are also available on a vanilla OS X.
Simply use python2.6 for Python 2.6.8:
$ python2.6
Python 2.6.8 (unknown, Mar 9 2014, 22:16:00)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
And python2.5 for Python 2.5.6:
$ python2.5
Python 2.5.6 (r256:Unversioned directory, Mar 9 2014, 22:15:03)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
While it can be convenient to have a pre-installed Python, my rookie advise is to not use it: Apple doesn’t always do a good job on keeping the Python runtime environment up to date, plus it can be cumbersome to play with permissions just to install third-party Python librairies, and finally, Apple has a tendency to wipe-out your site-packages with every major OS upgrade.
So I simply recommend to install Python aside the default one, with Homebrew. You’ll never have to use sudo or have permissions problem; if you have any issues, you can drop /usr/local and start from fresh without having messed up your OS X system. Let’s do it now!
2. Installing brew
There are many package installers on OS X but I find Homebrew very pleasant, simple and convenient. Homebrew, originally started by Max Howell, simplify the installation of open source tools (like ImageMagick, wget, ag etc..) that are not by default on OS X.
What I really like with Homebrew is that everything is installed in a directory that is not conflicting with the system directories. By default, it’s on /usr/local but you can change to whatever you like.
Installing Homebrew is very simple: open a Terminal window and type
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
3. Installing Python 2.7 with brew
Now that our Homebrew installation is done, we can install Python. We’re going to start by installing Python 2.7:
$ brew install python
Now, we need to tell the system to use our freshly new Python interpreter instead of the default one.
$ which python
/usr/bin/python
The default Python interpreter is under /usr/bin, and the Homebrew’s one is under /usr/local/bin so we’re going to edit /etc/paths so the /usr/local/bin binaries will be prioritised over /usr/bin.
$ sudo vi /etc/paths
If you open /etc/paths, you should see this:
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
Move /usr/local/bin at the beginning of the file so Homebrew binaries take on system binaries;
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
Finally, check everything is ok: typing python should launch the Homebrew version
$ source /etc/paths
$ which python
/usr/local/bin/python
$ python
Python 2.7.8 (default, Jul 2 2014, 10:14:46)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
pip has been also installed alongside our brewed Python; pip will allow us to easily install and manage Python packages.
$ which pip
/usr/local/bin/pip
With this setup (brewed python), you’ll NEVER have to use sudo to install any Python relative stuff. If you end up doing this, something is broken in your brewed Python installation.
4. Installing third-party libraries
4.1. Essential
There are two kind of third-party libraries: those you want to be installed anytime with your default Python, and those you like to play with, or use only for your toys projects. You don’t want to mess your default Python, so I recommend to install only the essential libraries in your default Python (which is /usr/bin/local/python if you’ve followed my previous advices).
Those essentials libraries depends on your needs, and will be different from one person to another. In Must-have packages, I’ve listed some open source packages that I found convenient to be always present in my system.
You’ll be able to install the other libraries in a virtual Python environment, that could be used and / or trash anytime, without messing up your brewed installation.
Let’s take the example of a library that I want to always be available in my Python interpreter: Requests. To install it, I simply pip install request in a terminal window. This way, each time I use my default Python, I can do HTTP requests really easily.
$ pip install requests
$ python
Python 2.7.8 (default, Jul 2 2014, 10:14:46)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> requests.__path__
[’/usr/local/lib/python2.7/site-packages/requests’]
>>>
4.2. virtualenv
Now, you could theoretically install all the third parties libraries you need in your default Python. But, imagine you have a script that needs version 1 of LibFoo, but another script requires version 2. How can you use both these scripts? If you install everything into /usr/local/lib/python2.7/site-packages/, it’s easy to end up in a situation where you unintentionally upgrade something that shouldn’t be upgraded.
Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.
To address this, we’re going to use virtualenv. virtualenv allows you to create an optimised, independent and sandboxed copy of your default Python. You’ll be able to install packages in this virtual Python environment, and only in this environnement. You will be able to use this Python interpreter (or activate it), play with it, and comes back (deactivate) to the default environnement. You will be able to have multiple venvs (shortcut for virtual Python environment), each one being completely independent of the others; you will be able to switch between environment, execute periodic scripts in a given environment etc…
To install virtualenv, just use your default pip:
pip install virtualenv
Example: you want to play with latest version of Django. So the first step is to create a venv for the latest version of Django. You can create a venv anywhere on your disk, and you do not need to be root to do this, you just need write permissions. For example, you can install a new venv in your Documents directory:
$ cd ~/Documents
$ virtualenv -p /usr/local/bin/python2.7 venv-django
This command has created a sandboxed version of your Python environment under the folder venv-django. By default, this copy comes clean, without the third-party packages that are installed in your default Python. This allows you to start from a clean, new state. You can open the folder ~/Documents/venv-django and you will see a sandboxed Python environment:
$ cd ~/Documents/venv-django
$ ls -l
total 0
drwxr-xr-x 19 jc staff 646 Sep 27 11:43 bin
drwxr-xr-x 3 jc staff 102 Sep 27 11:43 include
drwxr-xr-x 3 jc staff 102 Sep 27 11:43 lib
$ cd bin
$ ls -l
total 160
-rw-r--r-- 1 jc staff 2203 Sep 27 11:43 activate
-rw-r--r-- 1 jc staff 1259 Sep 27 11:43 activate.csh
-rw-r--r-- 1 jc staff 2472 Sep 27 11:43 activate.fish
-rw-r--r-- 1 jc staff 1129 Sep 27 11:43 activate_this.py
-rwxr-xr-x 1 jc staff 253 Sep 27 11:43 easy_install
-rwxr-xr-x 1 jc staff 253 Sep 27 11:43 easy_install-2.7
-rwxr-xr-x 1 jc staff 150 Sep 27 11:43 get_env_details
-rwxr-xr-x 1 jc staff 225 Sep 27 11:43 pip
-rwxr-xr-x 1 jc staff 225 Sep 27 11:43 pip2
-rwxr-xr-x 1 jc staff 225 Sep 27 11:43 pip2.7
-rw-r--r-- 1 jc staff 72 Sep 27 11:43 postactivate
-rw-r--r-- 1 jc staff 74 Sep 27 11:43 postdeactivate
-rwxr-xr-x 1 jc staff 69 Sep 27 11:43 preactivate
-rw-r--r-- 1 jc staff 75 Sep 27 11:43 predeactivate
lrwxr-xr-x 1 jc staff 9 Sep 27 11:43 python -> python2.7
lrwxr-xr-x 1 jc staff 9 Sep 27 11:43 python2 -> python2.7
-rwxr-xr-x 1 jc staff 12744 Sep 27 11:43 python2.7
A new python interpreter is here and ready to serve! But currently the Python interpreter is still the default one.
$ which python
/usr/local/bin/python
To switch to the interpreter of the venv, you need to activate it. source the bin/activate script that have been created in the venv folder:
$ source ~/Documents/venv-django/bin/activate
(venv-django)$
(venv-django)$ which python
/Users/jc/Documents/venv-django/bin/python
(venv-django)$ which pip
/Users/jc/Documents/venv-django/bin/pip
You can see that your shell prompt is now prefixed with the name of the current activated environment (very convenient). You can test that no third-party packages have been installed and that your virtual env is clean:
(venv-django)$ python
Python 2.7.8 (default, Jul 2 2014, 10:14:46)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named requests
>>>
You can use this new Python environment without fearing to break anything, or to bloat you default Python. activate simply add the virtual env Python binaries to your PATH, in front of system defined binaries. Each time we’ll use pip or python, we’ll use the ones that are in this sandbox.
Now, we can safely install Django in your new environment:
(venv-django)$ pip install django
(venv-django)$ python
Python 2.7.8 (default, Jul 2 2014, 10:14:46)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>>
To leave the current virtualenv, and go back to the default Python, just type deactivate in any path.
$(venv-django) deactivate
Back to the default Python, Django is not installed and everything is clear.
You don’t need to do the activate/deactivate dance each time you want to use a particular venv. Let’s say you want to execute a cron task checker.py. checker.py is using a virtual env defined at ~/Documents/venvs/myvenv. You can use the venv python interpreter to launch checker.py (without calling activate), and everything will just works, your script will be able to import any module defined in your venv:
$ ~/Documents/venvs/myvenv/bin/python checker.py
4.3. virtualenvwrapper
Working with multiple virtualenv can become really teddy and cumbersome: you have to switch and remember where is located the venv you want to use. This is where virtualenvwrapper comes to place: virtualenvwrapper is a set of extensions to virtualenv tool. You can easily list, create and delete virtual environments; all of your virtual environments are organized in one place.
Installing virtualenv is really simple, with your main Python:
pip install virtualenvwrapper
Next, you have to add source /usr/local/bin/virtualenvwrapper.sh to your shell startup file (on OS X, you can put this at the end of ~/.bash_profile).
Then, everything is set up and you can create a new venv:
$ mkvirtualenv env1
New python executable in env1/bin/python2.7
Also creating executable in env1/bin/python
Installing setuptools, pip…done.
(env1)~ $
By default, all your virtual environments will be created under ~/.virtualenvs/ but you can change it.
List all environnement:
$ workon
env1
env2
Switch on environnement env1:
$ workon env1
5. Shell scripts with Python
If you write shell scripts in Python, you can launch your script by simply call:
$ python myscript.py
This will execute your script, with the current python interpreter. If your script need a particular virtual environnement to run, you can run it in this virtual environment without having to activate it before. Simply hard code the python interpreter binary that ways:
$ /Users/jc/.virtualenvs/env1/bin/python myscript.py
This will execute the script myscript.py in the virtual environnement defined at /Users/jc/.virtualenvs/env1. All the packages that you have installed in this virtual environnement will be callable in the script.
If you want to call directly your script without typing python, add the proper permission on your script
$ chmod u+x myscript.py
And add the following shebang at the beginning of your script:
#!/usr/bin/env python
You can also point to a particular python interpreter if you want:
#!/Users/jc/.virtualenvs/env1/bin/python
Which is considerably less portable. #!/usr/bin/env python will use the current python interpreter of your shell session (which can be a virtualenv ones).
Finally, it’s a best practice to declare the encoding of your script file. On OS X, use UTF-8.
For example, the following script:
#!/usr/bin/env python
if __name__ == ’__main__’:
print("Hello こんにちは!")
will produced this error when executed:
File "./testutf8.py", line 5
SyntaxError: Non-ASCII character ’\xe3’ in file ./testutf8.py on line 5, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
With the proper encoding hint, everything works as it should be (you can even use emojis if you want!):
#!/usr/bin/env python
# -*- coding: utf-8 -*-
if __name__ == ’__main__’:
print("Hello こんにちは!")
$ ./testutf8.py
Hello こんにちは!
6. Must-have packages
I’m not a Python expert, and everyone’s needs are different so take this list with a grain of salt.
- Requests: simply HTTP for humans. If you deals with HTTP requests, just use Request and your life will get a lot easier.
- BeautifulSoup: parsing HTML and XML data. So good.
- SQLAlchemy: efficient and high-performing SQL toolkit.
- Pillow: imaging library (fork of the venerable PIL). Just works.
- lxml: another HTML XML processing tookit. You can prefer BeautifulSoup APIs, but BeautifulSoup can also use lxml as a parser. It’s a matter of choice, I prefer BeautifulSoup.
- Jinga: full featured template engine.
- Pyments: generic syntax highlighter for general use in all kinds of software such as forum systems, wikis or other applications that need to prettify source code.
If you want to do web development, you could try:
- Django: unavoidable. Django is the behemoth of the Python web framework. I love it, for the documentation, the admin interface, the ORM, and the built-in authentication support. If you need something smaller, you can use Flask or Bottle.
- Flask: fast, simple and lightweight micro web framework.
- Bottle: fast, simple and lightweight micro web framework.
Flask and Bottle are both excellent. Give both a try before deciding which one to use.
7. Python 3
Everything I’ve just said works for Python 2 or Python 3. Python 3 doesn’t come pre-installed on OS X, so if you want to install it, just use brew.
brew install python3
Then you can launch python3 and play with the new asyncio module:
$ python3
Python 3.4.1 (default, May 19 2014, 13:10:29)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>>
Python 2 and Python 3 can coexist without any problem. If you want to launch the Python 2 interpreter, just use python. If you want to use the Python 3 interpreter, just use python3; if you want to install packages in Python 2 library, just use pip, if you want to install packages in your Python 3 library, just use pip3….et voilà!!!.
You can create virtual env that will use Python 2 or Python 3, just use the -p option flag to target a specific Python. For instance:
mkvirtualenv -p /usr/local/bin/python3 testasyncio
Will construct a venv with Python 3.
8. IDEs on OS X
You can write Python code with vim but there are good and complete Python IDEs on OS X.
- PyCharm: my Python IDE of choice. Starting at $99, it totally worths it. There is also a free edition. My only (minor) grip is that it isn’t a totally native OS X app (and there are too much preferences!).
- Exedore: much lighter than PyCharm and written entirely in Cocoa/Objective-C so it feels right at home on your Mac. Give-it a try (free trial, then $9.99).
- PyDev: if you like Eclipse, PyDev is for you. I’ve tried it but prefer PyCharm.
9. Various tools
9.1. Fabric
Fabric is a command-line tool for streamlining the use of SSH for application deployment or systems administration tasks. I use it for deploying this blog from my Mac for instance. With Fabric, you can launch command as if you were on your server, and execute arbitrary Python functions via the command line.
For exemple, in a fabfile.py file you code:
from fabric.api import local
def prepare_deploy():
local("./manage.py test my_app")
local("git add -p && git commit")
local("git push")
And then on the command line, you can launch:
$ fab prepare_deploy
And the commands will be executed locally.
But the real power of Fabric it that it can run commands on your server, from your Mac! For instance:
env.hosts = [’example.com’]
def deploy():
code_dir = ’/srv/django/myproject’
with cd(code_dir):
run("git pull")
run("touch app.wsgi")
If you execute fab deploy, the commands will be sent from your Mac to your server (via SSH) and executed here! Fabric really simplify you deployment needs and you can deploy, run scripts on multiple servers easily. I use it to deploy the blog on our server, and we use it also to deploy our various Django projects.
From jc.
This article is really for 3D rookies like me that would like to play with SceneKit. SceneKit[1] is a high-level 3D framework, introduced in Mountain Lion, that allows reading, manipulating and displaying 3D scenes. SceneKit is now part of iOS, starting from iOS 8, allowing developers to easily integrate 3D graphics or develop 3D casual games on iPhone / iPad / iOther.
SceneKit supports the import of COLLADA scenes: COLLADA is an open XML file format for 3D assets, supported by a lot (if not all) 3D creation softwares (like Blender, Maya, Bryce etc…). If you’re new to 3D and just want to play with SceneKit, you can search for free COLLADA files on the web (*.dae), or use the ones included in Apple SceneKit samples (Vehicle, Bananas, or even the complete WWDC 2014 SceneKit session, available as a sample code!)
Besides using free models, you can also create your own using a 3D modelling tool: there are plenty of choices from free (Blender) to very expensive (Maya). On the mac, Cheetah3D is really an excellent, and not very expensive, alternative. For $69, you have a complete 3D modelling, rendering and animation software for OSX (buy directly on Cheetah3D web site or on the Mac App Store).
I’m just beginning to use Cheetah3D, and I really appreciate how easy is the creation of 3D models. Cheetah3D is also a native Cocoa app, with an intuitive, Macintosh-like user interface:
Cheetah3D on Mavericks.
Really a great software!
I’ve created this mug in a couple of minutes, following the first tutorial of Learn 3D with Cheetah3D 6, an excellent resource on Cheetah3D. To include this model in an iOS sample app, we need to first export it as a COLLADA file from Cheetah3D. Select File > Export, choose dae as File Format and save your file (or download it here).
Then, create a SceneKit sample, with Xcode 6: New Project > Single View Application.
Give it a product name:
Select the main storyboard of the document, Main.storyboard , then the ViewController scene, and remove the default view of the ViewController.
Now, in the right corner of Xcode, select the Object library (as in the screenshot), and drag and drop a SceneKit view on the view controller.
Now, some code! Open ViewController.m and add the following code:
@import SceneKit;
…
@implementation ViewController
…
- (void)viewDidLoad
{
[super viewDidLoad];
SCNView *myView = (SCNView *)self.view;
myView.scene = [SCNScene sceneNamed:@"mug.dae"];
myView.allowsCameraControl = YES;
myView.autoenablesDefaultLighting = YES;
myView.backgroundColor = [UIColor lightGrayColor];
}
We’ve just loaded our mug COLLADA file into the 3D scene view. Now, we need to import the file into our project: File > Add Files to "TestSK" and select our our mug.dae file. Then build and run:
Mmmm… Something must be missing, we don’t have any textures displayed in the simulator! In fact, we forget something really important when importing our COLLADA files from Cheetah3D. In COLLADA files, textures are referenced and not included in the file; in other terms, the mug.dae file is not sufficient, and must be accompanied by the textures files that it references. So, we just need to include our mug-diffuse.png texture in our project: File > Add Files to "TestSK" and select the mug-diffuse.png file. Before running again the sample, you can select the mug.dae file in Xcode, and check that everything looks good now:
Then, run the sample, et voilà !
The mug in the iOS simulator
More on SceneKit
WWDC 2012 - Session 504: Introducing Scene Kit
WWDC 2013 - Session 500: What’s New in Scene Kit
WWDC 2014 - Session 609: What’s New in SceneKit
WWDC 2014 - Session 610: Building a Game with SceneKit
From jc.
Tab bar is a standard navigation control present in iOS, since the first introduction of the iPhone. In the iOS Human Interface Guidelines,
A tab bar gives people the ability to switch between different subtasks,
view or modes in an app.
[…]
Use a tab bar to give users access to different perspectives on the same
set of data or different subtasks related to the overall function of your
app.
In general, use a tab bar to organize information at the app level. A tab
bar is well suited for use in the main app view because it’s a good way to
flatten your information hierarchy and provide access to several peer
information categories or modes at one time.
From gradient to flat
Tab bar has survived the iOS 7 shake-up, with minor modifications. From iOS 5 to iOS 7, the clock app tab bar’s looks like this:
Evolution of Clock’s tab bar from iOS 5 to iOS 7
Until iOS 6, tab bar icons were computed by applying a template blue gradient on a monocolor shape:
Looking closely, rendered icons also included a drop shadow and a light glowing stroke:
All third-parties apps using a tab bar exhibited the same blue bar icons (maybe with the noticeable exemption of the Nike+ app): there was no easy way using public APIs to change the icon blue rendering.
On iOS 7, the blue gradient is dropped to a flat, plain and customisable color (aka key color in iOS Human Interface Guidelines or tint color). Now, the clock tab bar looks like:
Appart from minor design modifications, the tab bar uses now two templates images for each icon: a selected/active one, and an unselected one:
The unselected icon is often just a thin silhouette of the selected icon. The selected image has more plain zone, filled with color: the attention is really focused on the selected icon. Another gain with the iOS 7 design is accessibility: even if you’re color blind, you can still see where is the selection.
Forgetting to use two different icons for the two different states is really a common mistake in a lot of iOS 7 apps (maybe due to the fact that you can’t use Interface Builder to set the image for each state). Programmatically, it’s straightforward using UITabBarItem instances:
NSString *imageOffName = @"ClockTabIconOff";
NSString *imageOnName = @"ClockTabIconOn";
tabBarItem.image = [UIImage imageNamed:imageOffName];
tabBarItem.selectedImage = [UIImage imageNamed:imageOnName];
iOS 6 experimentations
On iOS 6, a simple app built with the public SDK kept using the classic blue gradient. But some Apple apps showed that there were ’experimentations’ around where should go the iOS design. For instance, the App Store app used a ’flatter’ gradient, while keeping the blue selection against a black background:
App Store on iOS 5, 6 and 7
In the same time, the Music app used a completely greyed tab bar:
Music on iOS 5, 6, 7. Notice the black pixels in the bottom corners to give a "rounded" layout" in iOS 6.
Combine the new flat color selection of the App Store app and the lighter tab bar of the Music app, and we have something that can resemble to the iOS 7 aesthetic! What’s surprising is that the iOS 7 tab bar, while being a real departure from the past, has kept a familiar look and feel, and could be seen as another design iteration.
Back to basics
How to talk on tab bar and not mention Game Center? Introduced in iOS 4, Game Center (and more precisely the Game Center companion app) was the first built-in app to not use the classic blue icon / black background tab bar. It featured a rich faked wooden tab bar. Four releases latter, iOS 7 has come and put the Game Center app on the right track (more consistent, less fun):
From jc.
All graphics are now in beautiful, colourful 3D
Mickey in the Cloud
The Castle
You first boss, a friendly old tree!
One of the many puzzles: through the looking-glass
Another boss!
Miam miam, a sea of maccarons
The green diamond is over here!
A marshmallow dragoon!
How cute are these littles sugars!
Under the water, the vestige of an ancient city
