Information Systems:Setting up IBM i for Python development

Overview

This page documents the initial stages of Python development on the i. It is meant to be a running log of notes rather than a structured article as there is a lot of trial-and-error during this stage.

Notes

General

• On the IFS, /uwdsrc was created to be the root folder to house the source code for all further development.
• Krengeltech remains the best candidate as a 'Professional Services/Development Team', as they specialize in 5733-OPS, and have a close relationship with IBM in this area. Update: 12/2017 - We have purchased a block of hours with Krengeltech.
• Bitbucket and GitHub repos were created, but BitBucket will likely prevail as they offer free private repos (they're also preferred by Krengeltech for this reason).
• git is installed on the i (5733-OPS Option 6), and connections to Bitbucket and GitHub have been established i.e. /uwdsrc syncs to bitbucket.org:norwinu/uwdsrc.git. Also of fair importance, git on the i uses SSH keys (no HTTPS auth), so keys were generated using the IBM tools in PASE (likely based on openssl), and added to both repo sites.
• SSHd was enabled on the i as this is the proper way of interacting with the IFS to do the open-source stuff. I personally use bash through puTTY. The daemon starts and stops with TCP/IP.

• Note: Inaccessible from internet. Uses normal sign-in.

• I'm using PyCharm to code. It is dope.
• QDFTJRN is being explored as a way to automatically journal objects created in a specific library, which is needed for ibm_db.

Python

• Python 3 is installed through 5733-OPS Option 2. The current version is 3.4.4, but Python is constantly being updated through PTFs so this may change very soon. Python 2 will not be used but is installed (5733-OPS Option 4).
• Python has its package manager pip, which can be used to install modules from PyPI - the official Python repository. However, some modules are provided by IBM as PTFs. It is imperative that these modules be used instead. They are often older versions but are forks of the main project for the module and are verified to work for Python on IBM i. Upgrades to these modules should only be done through PTFs. The modules IBM provides are located in /QOpenSys/QIBM/ProdData/OPS/Python-pkgs. These whl files can be installed with pip (instead of fetching from the repo by default).
• The Python modules IBM ships through PTFs are:

• ibm_db (installed)
• ibm_db_django (installed)
• itoolkit (installed)
• flipflop (not installed)
• bottle (installed)

• sqlite3, as of 15:45, 14 June 2017 (PDT), does not work. See the Django section. Update: sqlite3 is now fully functional

Django

• Django 1.7 is verified to be the most workable version. 1.8 is supposed to be supported, but at this point it will be left at 1.7.
• Django is being tested through the built-in web server (i.e. 'python3 manage.py runserver) using port 8081.
• Apache does not yet support mod_wsgi, which is normally how Django would be hosted. gunicorn was installed using pip. Currently, the built-in, development server mentioned in the previous point will suffice, but gunicorn is production-ready and will be configured at a later stage. Apache should at that point be configured to proxy for gunicorn-hosted Django projects.
• sqlite3 (Python module) does not currently work. There is a pending PTF by IBM to fix this. Django uses this by default but since DB2 is going to be used as a backend, sqlite3 will not be necessary.
• ibm_db_django does not work out of the box i.e. it cannot successfully connect to DB2 for i. ibm_db_django/base.py and ibm_db_dbi.py had to be edited using workarounds. It might be worth it to fork these two modules into our own repo so we can maintain a changelog of the custom changes, but right now we're going to wait it out.
• Django creates tables for its admin app. Right now, these all reside in library/schema NORWINU. Django does not seem to natively support schemas, so it works inside whatever the current library is. DB2 SQL seems to always set the current library to the current username, which is why the Django tables were all created in NORWINU.
• Journal required: Further to the previous point, the initial Django setup (i.e. 'python3 manage.py migrate) errored out since it attempted to carry out a bunch of SQL operations. It turned out DB2 SQL requires tables to be journaled before allowing INSERT/ALTER operations. Thus, journal NORLIBJRN was set up to journal to journal receiver QJRNRECV in library NORWINU. Side note: this is actually the first time we've journaled on the i - it works pretty smoothly!