CMS Python Package Development: Glossary

Key Points

Python Package Set-up and Structure	There is a common way to structure Python packages You can use the CMS CookieCutter to quickly create the layout for a Python package
Git and GitHub	Git provides a way to track changes and differences between versions. git can be used with an online repository (GitHub) so that you can access a copy of your code from any machine
Python Coding Style	Your code should adhere to standards outlined in PEP8 so that it easily readable by others. All functions and modules should be documented with docstrings.
Code Collaboration using GitHub	To contribute to someone else’s project, you should fork their repository. All development work should be done on a new branch. Each branch should implement one feature. Once you’ve implemented a new feature, push to your repository and create a pull request on the original repo.
Python Testing	A good set of tests covers individual functions/features and behavior of the software as a whole. It’s better to write tests during development so you can check your progress along the way. The longer you wait to start the harder it is. Try to test as much of your package as you can, but don’t go overboard, most packages don’t have 100% test coverage.
Continuous Integration	Continuous integration services can be used to automatically test your code.
Documentation	Some documentation is better than no documentation
Community	Be kind to new developers Always make PR’s and issues.

Glossary

The glossary would go here, formatted as:

{:auto_ids}
key word 1
:   explanation 1

key word 2
:   explanation 2

({:auto_ids} is needed at the start so that Jekyll will automatically generate a unique ID for each item to allow other pages to hyperlink to specific glossary entries.) This renders as:

key word 1: explanation 1
key word 2: explanation 2