Hong Xu

Hong's Personal Technology Blog

Use Travis CI With Jython

| Comments

This page has been translated into Spanish language by Maria Ramos from Webhostinghub.com.

This post was updated on Feb 11, 2013, since the old way never works now. However, the original post is still available here.

Travis CI is a hosted continuous integration service for the open source community, helping run tests for your GitHub projects for every single push and pull request. However, by the time this post is written, Travis CI has not officially supported Jython, a Python interpreter written in Java. This post will help you setup a Jython testing environment for a Python project on Travis CI.

Setup a Basic Travis CI Configuration for Your Python Project

Before we add a Jython testing environment, we need to setup a basic configuration for the Python project. By reading the Getting Started page and Language-specific Guides for Python in the Travis CI Documentation, you should understand how Travis CI works, and the basic stuff of building your own configurations. Let’s suppose we have the following basic configuration file .travis.yml:

.travis.yml
1
2
3
4
5
6
7
8
9
10
# specify python as the language
language: python

# python versions to be used for testing
python:
  - "2.6"
  - "2.7"

# test script
script: python setup.py test

Now we could have our python project tested with Python 2.6 and 2.7 on Travis CI. Then, let’s add Jython as a Python interpreter for this project.

Add Jython Support for Your Python Project

You cannot simply append a jython item to the python list if you want your project tested with Jython, because Jython is not supported officially. But we can do something to make it work.

Here we need to take advantage of the Build Matrix feature of Travis CI. First, add env entries to the .travis.yml file:

1
2
3
4
5
6
7
python:
  - "2.6"
  - "2.7"

env:
  - JYTHON=true
  - JYTHON=false

Then what we need to do is to use Jython if JYTHON=true, and use C Python if JYTHON=false. However, the testing matrix has 4 entries, two of which are JYTHON=true entries, thus we need to let Travis CI ignore one of them. We could achieve this by appending the following lines:

1
2
3
4
matrix:
  exclude:
    - python: 2.6
      env: JYTHON=true

Then, tell Travis CI to install Jython by adding the following line to your .travis.yml file:

1
before_install: if [ "$JYTHON" == "true" ]; then sudo apt-get install jython; fi

By the time this post is written, the Jython version by sudo apt-get install jython is 2.2.x, which is a bit outdated. If you want to install a later version of Jython, such as 2.5.2, you could use the following lines instead of the line above:

1
2
3
before_install:
  - export JYTHON_URL='http://downloads.sourceforge.net/project/jython/jython/2.5.2/jython_installer-2.5.2.jar'
  - if [ "$JYTHON" == "true" ]; then wget $JYTHON_URL -O jython_installer.jar; java -jar jython_installer.jar -s -d $HOME/jython; export PATH=$HOME/jython:$PATH; fi

Then modify the test script to include the use of jython:

1
2
3
before_script: if [ "$JYTHON" == "true" ]; then export PYTHON_EXE=jython; jython -c "print ''"; else export PYTHON_EXE=python; fi

script: $PYTHON_EXE setup.py test

Note that we run jython -c "print ''" before we run the testing script, because something like the following may print when Jython run for the first time, which may affect the testing result:

*sys-package-mgr*: processing new jar, '/home/vagrant/jython/jython.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/resources.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/jsse.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/jce.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/charsets.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/ext/sunjce_provider.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/ext/gnome-java-bridge.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/ext/localedata.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/ext/dnsns.jar'
*sys-package-mgr*: processing new jar, '/usr/lib/jvm/java-6-openjdk/jre/lib/ext/sunpkcs11.jar'

The final .travis.yml should look like this:

.travis.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# specify python as the language
language: python

# python versions to be used for testing
python:
  - "2.6"
  - "2.7"

env:
  - JYTHON=true
  - JYTHON=false

matrix:
  exclude:
    - python: 2.6
      env: JYTHON=true

before_install: if [ "$JYTHON" == "true" ]; then sudo apt-get install jython; fi

before_script: if [ "$JYTHON" == "true" ]; then export PYTHON_EXE=jython; jython -c "print ''"; else export PYTHON_EXE=python; fi

script: $PYTHON_EXE setup.py test

Or like this:

.travis.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# specify python as the language
language: python

# python versions to be used for testing
python:
  - "2.6"
  - "2.7"

env:
  - JYTHON=true
  - JYTHON=false

matrix:
  exclude:
    - python: 2.6
      env: JYTHON=true

before_install:
  - export JYTHON_URL='http://downloads.sourceforge.net/project/jython/jython/2.5.2/jython_installer-2.5.2.jar'
  - if [ "$JYTHON" == "true" ]; then wget $JYTHON_URL -O jython_installer.jar; java -jar jython_installer.jar -s -d $HOME/jython; export PATH=$HOME/jython:$PATH; fi

before_script: if [ "$JYTHON" == "true" ]; then export PYTHON_EXE=jython; jython -c "print ''"; else export PYTHON_EXE=python; fi

script: $PYTHON_EXE setup.py test

In this way, there will be one more testing for Jython every time the testing is triggered.

A Real World Example

A real world example could be found here. The real world example uses cmake as its testing system so it looks a bit different from the example above.

Comments