Ben Nuttall ● Education Developer Advocate at the Raspberry Pi Foundation – Learning resources – Picademy – Outreach – events and conferences – Software development – Creative Technologists programme – raspberrypi.org ● From the North ● piweekly.net
Who should create the API? ● The company who made the product – i.e. Their employed software developer ● The mug who bought the product and found there was no API – i.e. You
Why should we (the company) create the API? ● Make it easy for users to make amazing things with your product ● Show what your product is capable of ● Share example code
Why should I (the user) create the API? ● First, badger the company to make one – Or offer to help ● Or just do it – Especially if it's easy ● You want to use the product, don't you? ● Personal pros: – It's good experience – Makes your GitHub profile look good – Maybe they'll hire you – Maybe someone else will hire you
Python 2 or Python 3? ● Both ● Python 3 is the present and future of the language ● Python 2 is legacy, but easy to support along with Python 3 ● Always start with Python 3 – It's easier to go backwards than forwards ● If your package depends on a package which is Python 2 only – Request a Python 3 version – Make a Python 3 version and send a PR – Find an alternative package – Weep at the thought that your package doesn't work in Python 3 ● All examples here are for supporting both Python 3 and Python 2
How? 1. Write code to access your hardware 2. Design API (plan example usage) 3. Create abstraction layer – e.g. functions 4. Create a module from the code (simple structure of files) 5. Upload to GitHub (naturally) 6. Test installing your module 7. Upload to PyPI (Python Packaging Index) 8. Users can now “pip install” your module
Write some code ● Think of an example use of the product – How do you do it the long way? e.g. using RPi.GPIO – Implement it ● Repeat for some or all basic usage
Design the API ● What should users be able to do with the API? ● How do you want to use the API? ● Write example usage, e.g: hat = MyHat() hat.green.on() hat.red.on()
Create abstraction layer ● Combine the example code with the API design ● Consider code architecture (keep it as simple as possible) – Procedural approach – functions only – Object oriented approach – wrapper class around functions to maintain state – Break into multiple classes if necessary
Upload to GitHub ● Sign up to github.com ● Create a repository ● add, commit, push, etc. (use git properly) ● Include a licence (see choosealicense.com) ● Include a contributing policy (CONTRIBUTING.md)
Test the module ● Python file – Create a Python file with your example usage – Start by importing your module – Test outside of your project folder! – Do not name this file the same as your module! – python3 myfile.py – python myfile.py ● Python shell – Same guidelines apply
Upload to PyPI ● Install requirements – sudo aptget install python3dev pythondev twine ● Check the namespace is available – http://pypi.python.org/pypi/my-hat ● Sign up to PyPI ● Register the package name – via website or – sudo python3 setup.py register
Upload to PyPI ● Create source distribution – python3 setup.py sdist ● Create built distribution – python3 setup.py bdist [options] ● Read up on Python Wheels ● Likely you can use Universal Pure Python wheels: – python3 setup.py bdist_wheel --universal ● Both in one go – python3 setup.py sdist bdist_wheel universal
Upload to PyPI ● See what was created – ls dist ● Built distribution (wheel) Source distribution ● myhat0.1.0py2.py3noneany.whl myhat0.1.0.tar.gz ● Upload! – twine upload dist/* ● Look it up on PyPI – http://pypi.python.org/pypi/my-hat
Good Examples ● Picamera – https://github.com/waveform80/picamera/ ● Anything by Dave Jones – https://github.com/waveform80 ● Sense HAT – https://github.com/RPi-Distro/python-sense-hat ● Energenie – https://github.com/RPi-Distro/python-energenie ● Explorer HAT – https://github.com/pimoroni/explorer-hat ● Anything by Pimoroni (Phil Howard) – https://github.com/pimoroni
Tips & Further Reading ● See “from future import X” for Python 3 features in Python 2 – https://docs.python.org/2/library/__future__.html ● Python Packaging User Guide – https://python-packaging-user-guide.readthedocs.org/en/latest/ ● Version sensibly – 1.1.0 1.1.1 1.1.2 1.1.3... (very minor changes) → → → – 1.1.6 1.2.0 (new features introduced or significant refactoring with API unchanged) → – 1.0.0 means feature complete – 1.3.5 2.0.0 (major change, breaks backwards compatibility) → ● Bump version number to alpha in testing locally – e.g. 3.1.4a0, 3.1.4a1, etc. ● Plan well – don't break backwards compatibility if you can avoid it
apt-get install? ● Packaging for Debian is hard work ● Packaging for PyPI is a good start ● See Debian packaging procedure – https://wiki.debian.org/Python/Packaging ● Good luck