L'emballage et l'expédition d'une bibliothèque python et des scripts, de la manière la plus professionnelle

Question

J'ai la tâche de l'emballage et de l'expédition des applications commerciales bundle, qui comprend:

1. une bibliothèque python (développé par nous)
2. certains programmes python en fonction de la bibliothèque ci-dessus
3. d'autres bibliothèques qui n'est pas développé par nous, mais qui sont des dépendances de notre bibliothèque.
4. complet d'installation de python (python 2.6)
5. d'autres choses, libs et des programmes dans d'autres langues. Pas un souci ici, car ils ne sont pas accrochés dans les machines ci-dessus, et l'actuel processus d'expédition travaille déjà.

Le module est livré à Linux, OSX et Windows. Sur Linux, il est distribué comme un simple tar.gz. Il suffit à l'utilisateur déballe tar.gz et source un script bash en .bashrc, de sorte que l'environnement est correctement réglé. Sur mac, c'est un dmg. Sur windows, je n'ai aucune idée. Le gars windows n'est pas ici aujourd'hui, mais ce que je vois c'est qu'un fichier exe est créé en quelque sorte.

Je vais maintenant vous expliquer plus en détail les points ci-dessus.

Notre Bibliothèque Python

Nous ne voulons pas donner de sources, de sorte que nous voulons vous fournir compilé uniquement des fichiers python. Une meilleure stratégie pour les rendre encore plus inviolable est la bienvenue, même si elle implique une certaine profondeur de piratage (par exemple, une fois j'ai vu la magie fait de l'importation de choses à partir d'un .zip qui a été "corrompu" ad-hoc). La bibliothèque à l'instant n'ont pas de niveau C ou de code similaire dépendants de la plateforme de code, mais cela va bientôt changer. Nous devrons donc nous fournir une plate-forme spécifique compilé .so ensemble avec le pyc.

Clairement, cette bibliothèque sera livrée dans l'emballage, ainsi que le reste de notre application. Il sera donc installé sur le téléchargé bundle. Pour cette raison, il doit être entièrement transférable, et l'utilisateur doit en quelque sorte (que ce soit manuellement ou par l'intermédiaire de notre env script) ajouter l'emplacement du paquet décompressé à PYTHONPATH, afin que l'interprète puisse le trouver.

Nos Programmes Python

Nous enverrons des applications dans notre bundle, et ces demandes dépendra de notre bibliothèque. Le code de ces applications doit être visible par l'utilisateur (afin qu'il puisse apprendre à utiliser l'interface de la bibliothèque), ou n'est pas visible (pour ces services, nous voulons garder closed-source), donc une double approche.

Bibliothèques Supplémentaires

Notre bibliothèque dépend de la 3e partie des bibliothèques, nous aurons à livrer, de sorte que l'utilisateur est en place et fonctionne sans aucune dépendance à la chasse. Clairement, ces bibliothèques seront installés par nous dans le paquet, mais nous devons nous espérons que ces ne pas stocker le chemin d'installation quelque part au cours de la construire, car cela les rendrait non délocalisables.

Notre python

Nous enverrons notre version de python, qui nous supposons que l'utilisateur exécutera afin d'accéder à notre script. C'est parce que nous voulons être sûr de la version de python en cours d'exécution. Aussi, on peut bricoler un peu l'exécutable ou la bibliothèque standard. On peut avoir une préoccupation au sujet de l'interaction de ce python avec le standard de python, et si l'utilisateur veut une bibliothèque spécifique sur notre python il faut l'installer à l'intérieur de notre solution groupée, et non sur la norme de place pour les bibliothèques.

Demande

J'ai besoin de faire mon esprit autour de cette tâche. Je l'ai vu faire, mais jamais fait personnellement, j'ai besoin de votre point de vue. Ce que j'ai présenté ci-dessus, je pense que les choses devraient fonctionner, selon la façon dont les choses sont aujourd'hui, mais il peut être mauvais. Tout soupçon, de l'excentricité, de la suggestion, ou d'une stratégie pour un déploiement réussi est la bienvenue. Compte tenu de la complexité de la question, j'ai déjà annoncer une grande générosité sur elle, selon la meilleure réponse que je peux obtenir.

Answer 1

Ce n'est pas une réponse complète mais tout un tas d'idées. J'ai écrit un programme d'installation pour un client qui a incorporé quelques idées qui pourraient vous être utiles.

C'était seulement pour Linux donc je me suis concentrée sur tout ce qui. Nous devions personnalisé spécifique versions de mySQL, lighttpd, python, memcached, à quelques la 3e partie des modules Python et quelques scripts personnalisés. Nous avons besoin de lancer tous ces services sans aucun problème et permettre à l'utilisateur de contrôler l'utilisation des scripts d'initialisation. Il devrait fonctionner sur un tas de populaire des distributions, et, par conséquent, ne comptez pas sur la distribution des choses spécifiques.

Ce que j'ai fait comme suit.

1. Créé un 500MO (je suis de ne pas se rappeler la taille du fichier et formaté comme un ext3fs système de fichiers.
2. Monté à un point à l'aide d'un périphérique de bouclage.
3. Couru deb-bootstrap sur le point de montage pour créer un custom installation de Debian.
4. "Chrooté" à l'intérieur de la partition, puis a couru un tas de scripts qui a fait un apt-get install sur tous nos dépendances, installé tous les œufs et d'autres paquets qui ont été nécessaires pour l'application, installé l'application elle-même dans /opt (à l'intérieur du chroot), installé supervisord (pour faire de la gestion de processus) et de mettre les choses en place. Maintenant, cette partition a été complètement autonome Linux système de fichiers qui contient l'application et tout le nécessaire pour l'exécuter. Vous pourriez faire un dump n'importe où, à l'intérieur du chroot et de lancer l'application. La seule dépendance qu'elle avait avec le monde extérieur ont été les ports qu'il utilisera pour ses services et la supervisord de contrôle de la socket. C'était le point principal. Nous avons été en mesure de comprendre exactement ce dont nous avions besoin (les fichiers compilés, .pycs seulement etc.) pour des exemples d'applications et de ne pas avoir à s'embêter avec les limitations éventuelles de la norme d'installation des outils.
5. Après cela, nous avons regroupé quelques scripts qui irait à l'externe du système d'exploitation. Ces ont été réalisés sur mesure pour chaque distro que nous aurions à supporter. Cette partie a été distro spécifiques. Il y avait des scripts qui vont en /etc/init.d et certains scripts qui serait d'installation de la base de données et des trucs au début.
6. Nous avons ensuite créé une archive de l'ensemble du système de fichiers à l'aide de makeself. Il serait de la somme de contrôle des trucs et tout ce qui et de fournir une archive auto-extractible qui s'fonctionner décompresser le tout à l' /opt sur la machine hôte, chroot à l'intérieur du répertoire et exécuter un script d'installation qui serait de demander à l'utilisateur quelques questions comme db nom d'utilisateur/mot de passe etc. et de mettre les choses en place. Après cela, il allait chercher les scripts que j'ai mentionné dans l'étape 5 et l'a mis sur l'OS hôte.

Les initscripts serait tout simplement chroot dans la partition et de commencer à supervisord. Il serait alors prendre soin de lancement de tous les services que nous pensions. L'arrêt de l'application est une simple question de connexion à l'exécution de supervisord et l'exécution d'une commande. Nous l'avons enroulé dans le script de démarrage afin que l'expérience utilisateur a été UNIX.

Maintenant, nous aimerions donner à ses clients les auto-extractible .run fichier. Ils me lancer, il me pose quelques questions et il serait de créer un sous-répertoire /opt qui contenait notre application et toutes ses dépendances. Les scripts d'initialisation serait modifié pour démarrer notre application sur le démarrage et les choses ne fonctionnent pas comme prévu.

Je pense que l'étape 4 vous donne la liberté d'installer ce que vous voulez, quand vous le voulez, de sorte que les choses fonctionnent bien.

Answer 2

Vous pouvez utiliser Makeself qui est juste comme un tar.gz, mais il produit une .sh qui s'auto-extraits et permet l'exécution d'un script d'installation personnalisée (ne me demandez pas sur Windows). Cela évite le regroupement installé Python qui est presque certainement ne fonctionne pas - vous pouvez inclure un programme d'installation à la place.

Votre code et les dépendances que vous avez développés devrait être inclus dans les packages créés par sdist, qui peut être installé par le PIP et easyinstall dans un virtualenv basé sur votre python. Dans votre Manifeste.vous pouvez facilement inclure uniquement pyc fichiers et tout ce qui est nécessaire et exclure py fichiers pour que personne ne voit vos sources. Les dépendances seront installés automatiquement par le téléchargement, mais vous pouvez éviter cela en les incluant dans votre archive, à l'instar de vos dépendances. Il suffit de les placer dans un répertoire et d'ajouter "-f fichier:path_to_your_directory" pour vous, PIP appel.

Answer 3

Je n'arrive pas à comprendre comment les utilisateurs utilisent le programme, donc toutes mes excuses si ce n'est pas utile.

Avez-vous regardé py2exe et py2app? Ils vous permettront de créer beaucoup plus d'obfuscation exécutable sur Windows et OS X, qui peut être encore plus facile. Moins de dépendance et que les choses aillent mal.

Nous avons déployé une interne, l'ensemble de l'entreprise app avec py2exe, et il a été négligeable. Indépendamment de ce que les autres pythons l'utilisateur avait ou n'avait pas notre script est un simple assistant, programme d'installation, et a travaillé de manière fiable. Il inclus un certain nombre de bibliothèques Python et C, nous avons dû bundle, avec un interpréteur python. Cependant, nous n'étions pas en essayant de masquer le contenu, il suffit de le rendre facile.

Answer 4

Je vais avoir le même problème, cependant, la plupart des informations que j'ai pu trouver était seulement sur les paquets python. Je n'ai pas de solution complète, mais encore, j'ai quelques suggestions.

1. Empêcher les dépendances de l'interpréteur python dans l'esprit, par exemple. sur Linux, python dépend de la version de la glibc. Essayez de compiler statiquement ou de l'utilisation d'un très commun de la glibc. Vous pouvez avoir un coup d'oeil à Activestate de la distribution python; le problème est qu'ils veulent BEAUCOUP d'argent pour cela.

2. Envisagez d'utiliser un format de paquet comme DEB ou RPM au lieu de tar.gz pour linux. Ceci devrait vous permettre de résoudre les dépendances, si il y a de tout et ferait un processus de mise à jour plus facile.

3. De même que vous, souhaitez distribuer votre application en tant que tar.gz je recommande la construction d'un paquet pour cette application. Pas nécessairement pour l'utilisateur, mais pour vous lors de la construction de l'environnement, qui doivent être exécutés sur un site client. Cela permettrait de tester et de développer et mettre à jour l'environnement de plus en plus facilement.

Answer 5

Cela peut varier en fonction de votre marché cible. Spécialisés dans les secteurs de niche, il n'y a plus de variété dans la façon dont des choses est distribué. Fortement banalisé domaines je m'attends à ce système d'exploitation natif paquet (au moins si j'étais un client). J'ai tendance à prendre la qualité de l'package de déploiement comme une indication de la qualité du logiciel en général. - Je associer système d'exploitation natif paquets de meilleure qualité que les autres formats en grande partie parce que les informations de dépendance peut être complète. Cela rend plus facile de faire quelques essais de conformité et la gestion du changement.

Système d'exploitation natif de Paquets

• For Unices envisager la création de système d'exploitation natif de paquets. Ils offrent une meilleure intégration et la visibilité grâce à des processus tels que la conformité, la gestion du changement, gestion de la dépendance, etc.
• Pour OSX d'autres l'ont déjà suggéré py2app. Vous pouvez également être en mesure de tirer parti de MacPorts format de package ou le paquet Fink format.
• Pour Windows, d'autres l'ont déjà suggéré py2exe.

Réinstallation et configuration des Exigences

• Mettez votre Python exécutable sous .../libexec. Cela l'empêche de accidentellement appelé.
• Changer le nom de l'exécutable Python, pour éviter la confusion. c'est à dire. /usr/local/libexec/<pkg>_python
• Distribuer l' .py pour les bacs pour les rendre facilement transportables. Vous pouvez modifier le Magic Cookie au moment de l'installation quelle que soit la localisation de votre Python a été installé via un script d'installation. Le seul code que vous avez besoin dans les bacs, c'est une ligne qui appelle à votre lib qui est un pyc.
• Installer votre libs dans l'emplacement approprié en vertu de l' /usr/local/lib/app_python/site_package/... et vous n'aurez pas besoin d'utiliser PYTHONPATH.

Bibliothèques Partagées

• Si je me souviens bien, vous voulez vous assurer que vous dépouiller de tout rpath des entrées de la libs comme cela peut mess avec leur capacité à être déplacés.
• Le système d'exploitation natif de l'emballage devrait aider avec toutes les dépendances de la shared libs besoin.