Distribuer une application Python

Pour les développeurs paresseux

Qui suis-je ?

Mon rôle à Ingeniweb sur l'aspect empaquetage/distribution

• formaliser la structure des applications
• industrialiser la mise en production
• mettre en place un processus de packaging
• fournir des outils aux devs

Plan

ceci n'est pas un tutoriel

• Empaqueter une application
• Fournir une application
• La révolution des Oeufs
• Distribuer une omelette
• Déploiement décentralisé
• PloneSoftwareCenter

Empaqueter une application

• Méthode 1: méthode R.A.C.H.E
• Méthode 2: distribution par source
• Méthode 3: distribution binaire

Méthode 1: RACHE

1. créer un module python launch.py, main.py

2. y glisser le code de démarrage:

   import mon_appli
   import sys
   
   if __name__ == '__main__':
       mon_appli.se_lance(sys.argv)
   

Méthode 1: RACHE

Avantages:

• portable
• sûr de fonctionner
• pas de problèmes de désinstallation

Inconvénients:

• installation manuelle
• démarrage manuel et spécifique
• pas d'intégration au système hôte
• modules C à compiler

et à terme : http://www.cafenware.org/la-rache/index.php?z=2

Empaqueter une application

• Méthode 1: méthode R.A.C.H.E
• Méthode 2: distribution par source
• Méthode 3: distribution binaire

Méthode 2: distribution par source

• Méthode R.A.C.H.E améliorée:

  • source déployé dans Python (site-packages)
  • mise en place de scripts de démarrage

• basé sur distutils

Méthode 2: distribution par source

Avantages:

• préparation automatique
• installation standardisée
• installation universelle

Inconvénients:

• désinstallation manuelle
• installation universelle (pas de .deb, etc)
• modules C à compiler

Empaqueter une application

• Méthode 1: méthode R.A.C.H.E
• Méthode 2: distribution par source
• Méthode 3: distribution binaire

Méthode 3: distribution binaire

Méthode 2 +

• pré-compilation des extensions C

Avantage:

• pas de compilateur nécessaire

Inconvénient:

• compilation à faire pour toutes les plate-formes cibles
• difficulté de la compilation statique

Show-time !

• on créé un paquet distutils
• on créé une distribution avec "sdist"
• on écoute The Pharcyde

Fournir une application

• Méthode 1: Site web
• Méthode 2: PyPI - http://pypi.python.org

Méthode 1 - Site web

Avantages:

• media central d'infos sur le projet
• organisation sur-mesure

Inconvénients:

• création de scripts pour pusher les distributions
• marketing nécessaire

Fournir une application

• Méthode 1: Site web
• Méthode 2: PyPI - http://pypi.python.org

Méthode 2 - PyPI

Avantages:

• automatique via distutils
• visibilité publique des paquets
• répertorié

Inconvénients:

• visibilité publique des paquets
• mise en ligne de doc limitée
• anonymisation
• maintien de deux media (site web+PyPI)

Show-time !

• on register et on upload sur PyPI
• on écoute Bauchlang

La révolution des Oeufs

Inconvénient des paquets:

• tout est inclus dedans
• grosse application = gros paquet
• non modulaire
  • une petite modif = release complète
• problème des dépendances:
  • README.txt: liste de bibliothèques à installer :(

La révolution des Oeufs

Et... les eggs fûrent

http://www.albinoblacksheep.com/flash/eggsong

La révolution des Oeufs

setuptools:

• développé par PEAK (Philip J. Eby)
• extension de distutils
• à terme remplacera distutils (Python 2.7 ?)

La révolution des Oeufs

setuptools permet de:

• découper une application en paquets grâce au namespace
  • zope.publisher
  • zope.security
  • etc.
• définir des dépendances
  • autoinstallation à la apt
• faire une installation develop
• installer avec une commande easy_install
• compatible PyPI

La révolution des Oeufs

Découper une application en paquets:

• distribution modulaire
• réutilisation maximisée

Show-time

• Egg-ification de l'exemple:
  • passage à setuptools
  • ajout de dépendances
  • création d'un .egg
  • develop

Distribuer une omelette

• Méthode 1: un master egg
• Méthode 2: environnement de configuration

Méthode 1: un master egg

Avantages:

• dépendances faciles à gérer
• récupération automatique des mis à jour

Inconvénients:

• désinstallation manuelle
• conflits de versions de paquets dans Python

Méthode 2: environnement de configuration

zc.buildout permet de:

• décrire les dépendance
• décrire la séquence de construction
• créer des scripts d'installation : les recettes
• de configurer, d'installer des applications tierces
• de fournir des scripts de démarrage

Show-time

Présentation d'un fichier buildout pour Plone.

• récupère les eggs python, zope, plone
• compile et install Zope dans le repertoire en cours
• fourni des scripts de pilotage

-> lancer la construction d'un Plone

zc.buildout

utilisé pour:

• Zope
• Plone
• Grok
• Les projets au dessus de Plone ou Zope

zc.buildout

zc.buildout existe car:

• Python gère mal les paquets !

  • mais PEP 370 accepté la semaine dernière

    http://www.python.org/dev/peps/pep-0370/

• setuptools est au niveau paquet

zc.buildout

Avantages:

• standard simple pour installer un projet:

  wget http://projet/buildout.cfg && wget http://projet/bootstrap.py
  python bootstrap.py && bin/buildout
  

• permet de gérer aussi le déploiement:

  • archivage et distribution d'un buildout pre-construit

• pas de conflits

• distribution universelle

zc.buildout

Installation localisée, pas de conflit ou de problèmes de désinstallation

zc.buildout

Inconvénients :

• buildout-centrism

  • pas d'intégration au Python du système
  • pas de .deb, .exe (mais peut etre une base pour)

• pypi-centric:

  • les eggs sont déployés sur PyPI
  • recettes maison pour les applications non publiques

Déploiement décentralisé

Problématique:

• comment construire et déployer des applications privées ?

Solution:

• gérer son PyPI privé !

Déploiement décentralisé

Problématique:

• comment construire et déployer des applications privées ?

Solution:

• gérer son PyPI privé !

Déploiement décentralisé

http://tarekziade.files.wordpress.com/2008/05/collective-dist.png

Mes travaux dans ce domaine

• Rendre disutils multi-serveurs (.pypirc)
• Créer une implémentation du serveur PyPI
• Déployer cette implémentation dans ma communauté Plone
• Promouvoir cette approche

Mes travaux dans ce domaine

• Rendre disutils multi-serveurs (.pypirc)

  • DONE : inclu dans le trunk de Python, pour python 2.6
  • en attendant 2.6: dispo dans collective.dist

• Créer une implémentation du serveur PyPI

  • DONE : PloneSoftwareCenter

• Déployer cette implémentation dans ma communauté Plone

  • DONE: plone.org migre dessus courant Juin

• Promouvoir cette approche

  • heu.. cette présentation ?

Utilisation actuelle concrète

Construction d'applications Plone avec:

• public: http://pypi.python.org
• public, spécifique à Ingeniweb: http://products.ingeniweb.com
• privé: http://entreprise/catalogue/d/eggs

Manque de temps

J'aurais voulu de parler de:

• La création de recettes pour buildout
• Paster: création de templates pour le boiler-plate code
• python-win32: installer pour rendre windows "buildout-ready"

Merci

Merci pour votre attention !

Merci à Olivier Grisel (essayez son paquet virtualkeyring)

Questions ?