======  Aanleveren van een Python applicatie ======

Applicaties kunt u zelf plaatsen door ze op de upload-server in de
juiste web-app directory neer te zetten. Het is ook mogelijk dit door
NPO Hosting en Streaming te laten doen. Wij gaan er dan vanuit dat er 1
complete tar file aangeleverd wordt (bv dmv een url waarvan wij de
tar file kunnen downloaden). Vervolgens zullen wij de tar file
plaatsen. Wij verwachten dat naast de tar file installatie
instructies aangeleverd worden.

Het configureren van de passenger/nginx wordt altijd door
NPO Hosting en Streaming gedaan. Idem voor databases.

Het configureren van de applicatie zal meestal in samenspraak tussen
NPO Hosting en Streaming en de sitebouwer gebeuren. Zaken waar NPO Hosting en Streaming zich
mee bemoeit zijn:

  * Database parameters ''config/settings.yml''; de database wordt door NPO Hosting en Streaming aangemaakt. login namen en database passwords zijn daar eventueel op te vragen)
  * Applicatie logfiles; Een python applicatie wordt geacht te loggen onder ''/e/ap/X/log'' houd er rekening mee dat er altijd meerdere python instanties hierin schrijven, maak een apart logfile voor elke instantie, neem bijvoorbeeld de uid op in de bestandnaam.
  * tmpdir; De applicatie tmpdir van een applicatie X wordt geacht te zijn:· ''/e/ap/X/tmp''
  * packages (modules); Binaire (gecompileerde) packages willen wij graag compileren om makkelijk software en OS upgrades uit te kunnen voeren. Overige modules worden geacht in de applicatie geïnstalleerd te worden
  * current; De applicatie wordt geacht te staan in /e/ap/X/pages/current/passenger_wsgi.py waarbij ''current'' meestal een symlink zal zijn naar de meest recente deployments.

Bij initiële oplevering plaatst NPO Hosting en Streaming een ''hello world'' applicatie
om een werkende set-up te kunnen tonen.
Deze kunt u uiteraard naar believen overschrijven of verwijderen.

Per applicatie wordt een bijbehorende python 'binary' opgeleverd
Voor een applicatie X is dat
<code>
/e/ap/X/bin/python
</code>
deze sourced z'n environment variabelen uit:
<code>
/e/ap/X/bin/env
</code>

Gebruik dit ook in je eigen shell om altijd de juiste python te gebruiken
voor command-line werk.
<code>
source /e/ap/X/bin/env
python --version
</code>
Indien gewenst kunnen wij hier meer environment variabelen in opnemen zoals
PYTHONPATH of DJANGO_SETTINGS_MODULE.

==== pip install ====
Zo maak je je eigen python packages repository:
<code>
source /e/ap/X/bin/env
pip install --prefix=/e/ap/X/pages/env SomePackage
</code>
Zie
[[https://pip.pypa.io/en/stable/user_guide/#installing-packages|hier]]
voor meer details.

Vervolgens kan via ''PYTHONPATH'' aangegeven worden waar deze packages
gevonden kunnen worden:
  export PYTHONPATH=/e/ap/X/pages/env/lib/python2.7/site-packages
of in geval van python3.6
  export PYTHONPATH=/e/ap/X/pages/env/lib/python3.6/site-packages

LET OP: niet alle packages kunnen via "pip install" geïnstalleerd
worden, namelijk als er software gecompiled moet worden kan dat vaak
niet. In zo'n geval kan
NPO Hosting en Streaming een module samenstellen waar de gewenste packages in zitten.
Deze wordt dan beschikbaar gesteld via
''/local/python-poilib-<iets>/...''
en middels het zetten van ''PYTHONPATH'' gerefereerd via ''/e/ap/X/bin/env''.

==== virtualenv / pyvenv ====
De python-wereld kent zoiets als een virtualenv welke kan
worden opgebouwd met 'virtualenv' of met 'pyvenv'.
Voor python-3 geldt dat dit probleemloos kan.

Voor python-2[.7] is het zo dat virtualenv een kopie van de python
binary maakt. Dat is op zich geen probleem, totdat er een upgrade van
python langskomt. In zo'n geval kan het voorkomen dat de virtualenv na
de upgrade niet meer werkt. Voor python-2 omgevingen adviseren we om
als er vanuit NPO Hosting en Streaming python upgrades aangekondigd worden na de upgrade
de virtualenv opnieuw aan te maken, om er zeker van te zijn dat deze
goed blijft samenwerken met de ge-upgrade python versie.

==== python versies op het systeem ====
Zoals hierboven uitgelegd koppelen we meestal een python binary 1-op-1
aan een website. Deze staat voor website X dan in
	/e/ap/X/bin/python
Als je in beter kijkt zie je dat die niet een echte binary is, maar een
shellscript waar ''/e/ap/X/bin/env'' ingelezen wordt en vervolgens de
echte python binary geëxecuteerd wordt. In ''/e/ap/X/bin/env'' staat
de locatie van de eigenlijke python binary en eventueel de locatie van
extra packages die nodig zijn voor website X.

De locatie van de eigenlijke python binary is voor python-2 installaties
is meestal
	/local/Python27-minimal/bin/python
of
	/local/Python36-minimal/bin/python
voor python-3.

Waarbij /local/Python27-minimal (en /local/Python36-minimal) symlinks
zijn naar een zeer kale standaard python installatie, waar eigenlijk
alleen ''pip'' en ''virtualenv'' aan zijn toegevoegd.

Op die manier kan men zelf middels ''pip install'' extra packages
installeren **en** kan NPO Hosting en Streaming onderhoud op python uitvoeren door
/local/Python27-minimal van tijd tot tijd naar een nieuwere python
versie te laten wijzen (b.v. van Python-2.7.13 naar Python-2.7.14)
zonder dat de bestaande ''pip install'' packages hiervoor aanpassingen
behoeven.

Naast /local/Python[XY]-minimal is er ook een python binary in
/usr/bin/python. Dit is de python versie zoals die standaard met het OS
meekomt en door componenten in het OS gebruikt wordt. Deze is niet
geschikt om webhosting mee te doen en kan hier dus beter niet voor
gebruikt worden. Om te voorkomen dat deze versie per ongeluk toch
gebruikt wordt is het zaak om altijd
	source /e/ap/X/bin/env
te doen zodat de juiste versie van python op het systeem gebruikt wordt.

==== Herstarten applicatie ====
Het herstarten van de applicatie kunt u zelf veroorzaken door een ''touch'' van
''/e/ap/X/pages/restart.txt'' uit te voeren.