Metadata-Version: 2.1
Name: ou-tm129-py
Version: 0.0.7
Summary: Python environment for TM129
Home-page: https://github.com/innovationOUtside/innovationOUtside/ou-tm129-py
Author: Tony Hirst
Author-email: tony.hirst@open.ac.uk
License: MIT License
Platform: UNKNOWN
Classifier: Development Status :: 3 - Alpha
Classifier: Environment :: Web Environment
Classifier: Intended Audience :: Education
Classifier: License :: Free For Educational Use
Classifier: Programming Language :: Python :: 3.6
Classifier: Programming Language :: Python :: 3.7
Classifier: Topic :: Education
Classifier: Topic :: Scientific/Engineering :: Visualization
Description-Content-Type: text/markdown
Requires-Dist: myst-nb
Requires-Dist: jupytext
Requires-Dist: jupyter-server-proxy
Requires-Dist: nbzip
Requires-Dist: nbresuse
Requires-Dist: nbgitpuller
Requires-Dist: tqdm
Requires-Dist: jupyter-contrib-nbextensions
Requires-Dist: jupyter-wysiwyg
Requires-Dist: jupyterthemes
Requires-Dist: nbtutor
Requires-Dist: RISE
Requires-Dist: nb-extension-tagstyler
Requires-Dist: nb-extension-empinken
Requires-Dist: nb-cell-execution-status
Requires-Dist: ipywidgets (>=7.5.0)
Requires-Dist: nbconvert (>=5.5.0)
Requires-Dist: drawSvg
Requires-Dist: blockdiag
Requires-Dist: blockdiagMagic
Requires-Dist: noisify
Requires-Dist: flake8
Requires-Dist: pycodestyle
Requires-Dist: pycodestyle-magic
Requires-Dist: autopep8
Requires-Dist: pep8-naming
Requires-Dist: flake8-bugbear
Requires-Dist: flake8-docstrings
Requires-Dist: flake8-builtins
Requires-Dist: pandas-vet
Requires-Dist: numpy
Requires-Dist: pandas
Requires-Dist: matplotlib
Requires-Dist: plotly
Requires-Dist: seaborn
Requires-Dist: cufflinks
Requires-Dist: durable-rules
Requires-Dist: nbev3devsim
Requires-Dist: nbev3devsim (>=0.0.6)
Requires-Dist: sklearn
Requires-Dist: palettable
Provides-Extra: al
Provides-Extra: production

# ou-tm129-py
Python package for installing Python packages required for TM129

This repo is exploring how we might distribute Python packages to students via a single installable package.

A Python package can be "empty" other than requiring the presence of particular packages.

We can define multiple levels of requirement using `install_requires=[]` for necessary packages and `extras_require={}` for optional packages.

Optional package collections can be installed via eg `pip install .[jupyter,production]`, using `extras_require` dictionary keys for the additional package collections we want to install.

So for example, we could deliver:

- core packages that configure a base Python environment: `pip install PACKAGE`;
- core packages and packages that customise a Jupyter environment in a particular way: `pip install PACKAGE[jupyter]`;
- core packages and packages that customise a Jupyter environment in a particular way and provides additional packages for ALs: `pip install PACKAGE[jupyter,AL]`;
- core packages plus production / development packages: `pip install PACKAGE[dev]`;
- core packages plus packages required to customise an OU hosted environment: `pip install PACKAGE[ouhosted]`;
- etc.

We could also use a package to deliver payloads to the student desktop, either in terms of files or services. eg we could supply command line utilites, a simple webserver/homepage, or a data files via a Python package.

Using Package version numbers (or `extras_require`) we could easily manage slightly different package versions/distributions for different module presentations.

Using `pip install --upgrade PACKAGE` gives us a way of pushing updates to students.

Note that installing from repos is increasingly tricky to do; it's no longer supported from PyPi installed packages, so if things were only available from a (public) repo they'd have to be done manually. (We could provide a cli tool to do this, installed from the package; eg `tm129_utils install-extras` that runs a `pip git+...` set of installs.)

I'm not sure if [Python package namespaces](https://packaging.python.org/guides/packaging-namespace-packages/) are also relevant? These let you package separate distributions but under the same namespace. Eg we could have separate packages for different modules but all under the `ou` or `openuni` or `openuniversity` namespace? (So we'd have things like `from openuniversity import tm351` etc. and installed via `pip install openuni-tm351` or `pip install openuni-tm129==2020.10.1` or whatever (is there a restriction or limits on the version numbering convention? Does it have to be numeric? Inside a certain range?)

Identifying what packages can support an effective teaching and learning environment is an act of curation, and as such is somewhere where we can add value. By sharing environments that may be useful to others:

- we support folk in their own teaching and learning, work and play;
- we raise awareness of the OU and OU modules, getting a presence on PyPi, maybe using `ou` and course code identifiers in package names etc;
- if we ship useful commmand line utilities, they can occasionly print OU advertising messages when run...
- if we ship a a simple web server, it can include module marketing information, "are you read for..?" activities or even sample module content;
- if we bundle files in the package, these can be retrieved on the student desktop via a simple CLI command; (can we also get desktop shortcuts onto a desktop some how?)
- the same package could be used to easily support related OpenLearn content;


