Mon objectif est de distribuer un package Python qui a plusieurs autres packages Python comme dépendances. Mon package dépend de packages bien écrits et indexés par Pypi comme les pandas , scipy et numpy, et spécifie dans le fichier setup.py que certaines versions ou plus sont nécessaires, par exemple "numpy> = 1.5".
J'ai trouvé que c'était extrêmement frustrant et presque impossible pour les utilisateurs avertis d'Unix qui ne sont pas experts en Python packaging (même si ils savent comment écrire en Python) pour installer un package comme le mien, même lorsqu'ils utilisent des gestionnaires de packages censés être faciles à utiliser. Je me demande s'il y a une alternative à ce processus douloureux que quelqu'un peut offrir, ou si mon expérience reflète l'état actuel très difficile de Python packaging et distribution.
Supposons que les utilisateurs téléchargent votre package sur leur système. La plupart essaieront de l'installer "naïvement", en utilisant quelque chose comme:
$ python setup.py install
Étant donné que si vous suivez les instructions de Google pour installer Python, c'est généralement ce qui se produit. Cela échouera pour la grande majorité des utilisateurs, car la plupart n'ont pas d'accès root sur leurs serveurs Unix/Linux. Avec plus de recherche, ils découvriront l'option "--prefix" et essayeront:
$ python setup.py install --prefix=/some/local/dir
Étant donné que les utilisateurs ne sont pas conscients des subtilités de Python, ils choisiront un répertoire arbitraire comme argument pour --prefix
, par exemple. "~/software/mypackage/"
. Ce ne sera pas un répertoire bien organisé où tous les autres packages Python résident, car encore une fois, la plupart des utilisateurs ne sont pas au courant de ces détails. S'ils installent un autre package "myotherpackage", ils pourraient le passer "~/software/myotherpackage"
, et vous pouvez imaginer comment cela entraînera un piratage frustrant de PYTHONPATH
et d'autres complications.
En poursuivant le processus d'installation, l'appel à "setup.py install"
avec "--prefix"
échouera également une fois que les utilisateurs essaieront d'utiliser le package, même s'il semble avoir été installé correctement, car l'une des dépendances peut être manquante (par exemple pandas, scipy ou numpy) et aucun gestionnaire de package n'est utilisé. Ils essaieront d'installer ces packages individuellement. Même en cas de succès, les packages ne seront inévitablement pas dans le PYTHONPATH
en raison des répertoires non standard donnés à "--prefix"
et les utilisateurs patients vont essayer de modifier leur PYTHONPATH
pour que les dépendances soient visibles.
À ce stade, les utilisateurs pourraient être informés par un ami Python averti qu'ils devraient utiliser un gestionnaire de paquets comme "easy_install"
, le gestionnaire principal, pour installer le logiciel et prendre en charge les dépendances. Après l'installation de "easy_install"
, ce qui pourrait être difficile, ils essaieront:
$ easy_install setup.py
Cela échouera également, car les utilisateurs ne sont généralement pas autorisés à installer le logiciel globalement sur les serveurs Unix de production. Avec plus de lecture, ils découvriront le "--user"
option, et essayez:
$ easy_install setup.py --user
Ils obtiendront l'erreur:
usage: easy_install [options] requirement_or_url ...
or: easy_install --help
error: option --user not recognized
Ils seront extrêmement perplexes pourquoi leur easy_install
n'a pas le --user
option où il y a clairement des pages en ligne décrivant l'option. Ils pourraient essayer de mettre à niveau leur easy_install
à la dernière version et constate qu'elle échoue toujours.
S'ils continuent et consultent un Python, ils découvriront qu'il existe deux versions of easy_install
, tous deux nommés "easy_install"
afin de maximiser la confusion, mais une partie de "distribuer" et l'autre partie de "setuptools". Il se trouve que seul le "easy_install"
de "distribute"
les soutiens "--user"
et la grande majorité des administrateurs de serveurs/systèmes installent "setuptools"
's easy_install
et donc l'installation locale ne sera pas possible. Gardez à l'esprit que ces distinctions entre "distribute"
et "setuptools"
sont vides de sens et difficiles à comprendre pour les personnes qui ne sont pas des experts en gestion de packages Python.
À ce stade, j'aurais perdu 90% des utilisateurs, même les plus déterminés, avertis et patients, qui tentent d'installer mon progiciel - et à juste titre! Ils voulaient installer un logiciel qui était écrit en Python, et non devenir des experts de l'état de l'art Python distribution de paquets, et c'est beaucoup trop déroutant et complexe. Ils donneront et être frustré par le temps perdu.
La petite minorité d'utilisateurs qui continuent et demandent plus Python seront informés qu'ils doivent utiliser pip/virtualenv
au lieu de easy_install
. Installer pip
et virtualenv
et comprendre comment ces outils fonctionnent et en quoi ils sont différents des outils conventionnels "python setup.py"
ou "easy_install"
les appels sont en soi longs et difficiles, et encore trop demander aux utilisateurs qui voulaient simplement installer un simple morceau de logiciel Python et l'utiliser. Même ceux qui poursuivent cette voie être confus quant à savoir si les dépendances qu'ils ont installées avec easy_install
ou setup.py install --prefix
sont toujours utilisables avec pip/virtualenv
ou si tout doit être réinstallé à partir de zéro.
Ce problème est exacerbé si un ou plusieurs des packages en question dépendent de l'installation d'une version de Python différente de celle par défaut. La difficulté de s'assurer que votre Python utilise la version Python que vous souhaitez, et que les dépendances requises sont installées dans le répertoire Python 2.x et pas Python 2.y, sera tellement frustrant pour les utilisateurs qu'ils abandonneront certainement à ce stade.
Existe-t-il un moyen plus simple d'installer Python logiciel qui ne nécessite pas que les utilisateurs se plongent dans tous ces détails techniques de Python packages, chemins et emplacements? Pour par exemple, je ne suis pas un gros utilisateur Java, mais j'utilise occasionnellement des outils Java), et je ne me souviens pas d'avoir à me soucier de X et Y dépendances du logiciel Java que j'installais, et je n'ai aucune idée du fonctionnement de la gestion des packages Java (et je suis heureux de ne pas le faire - Je voulais juste utiliser un outil qui était écrit en Java.) Si je me souviens bien, si vous téléchargez un Jar, vous l'obtenez et il a tendance à fonctionner.
Existe-t-il un équivalent pour Python? Un moyen de distribuer le logiciel d'une manière qui ne dépend pas des utilisateurs devant chasser toutes ces dépendances et versions? Un moyen de peut-être compiler tous les packages pertinents dans quelque chose d'unique qui peut simplement être téléchargé et utilisé comme binaire?
Je tiens à souligner que cette frustration se produit même avec l'objectif étroit de distribuer un package aux utilisateurs Unix avertis, ce qui rend le problème plus simple en ne se souciant pas des problèmes multiplates-formes, etc. Je suppose que les utilisateurs sont avertis Unix, et pourraient même connaissent Python, mais ne sont tout simplement pas au courant (et ne veulent pas être mis au courant) des tenants et aboutissants de l'emballage Python et de la myriade de complications/rivalités internes des différents gestionnaires de paquets). Une caractéristique inquiétante de ce problème est qu'il se produit même lorsque toutes vos dépendances de package Python sont des packages Pypi bien connus, bien écrits et bien entretenus comme Pandas, Scipy et Numpy. Ce n'est pas comme si je comptais sur des dépendances obscures qui ne sont pas des packages correctement formés: j'utilisais plutôt les packages les plus courants sur lesquels beaucoup pourraient s'appuyer.
Toute aide ou conseil à ce sujet sera grandement apprécié. Je pense que Python est un grand langage avec de grandes bibliothèques, mais je trouve quasiment impossible de distribuer le logiciel que j'écris dedans (une fois qu'il a des dépendances) d'une manière facile à installer pour les gens Je veux préciser que le logiciel que j'écris n'est pas une bibliothèque Python pour une utilisation programmatique, mais un logiciel qui a des scripts exécutables que les utilisateurs exécutent en tant que programmes individuels. Merci.
Nous développons également des projets logiciels qui dépendent de numpy, scipy et d'autres packages PyPI. De loin, le meilleur outil actuellement disponible pour gérer les installations à distance est zc.buildout . Il est très facile à utiliser. Vous téléchargez un script d'amorçage à partir de leur site Web et le distribuez avec votre package. Vous écrivez un fichier de "déploiement local", appelé normalement buildout.cfg
, qui explique comment installer le package localement. Vous expédiez à la fois le bootstrap.py
fichier et buildout.cfg
avec votre colis - nous utilisons le MANIFEST.in
fichier dans nos packages python pour forcer l'incorporation de ces deux fichiers avec les boules Zip ou tar distribuées par PyPI. Lorsque l'utilisateur le décompresse, il doit exécuter deux commandes:
$ python bootstrap.py # this will download zc.buildout and setuptools
$ ./bin/buildout # this will build and **locally** install your package + deps
Le package est compilé et toutes les dépendances sont installées localement , ce qui signifie que l'utilisateur qui installe votre package n'a même pas besoin des privilèges root, ce qui est une fonctionnalité supplémentaire . Les scripts sont (normalement) placés sous ./bin
, afin que l'utilisateur puisse simplement les exécuter après cela. zc.buildout
utilise setuptools
pour l'interaction avec PyPI, donc tout ce que vous attendez fonctionne tout de suite.
Vous pouvez étendre zc.buildout
assez facilement si toute cette puissance n'est pas suffisante - vous créez les soi-disant "recettes" qui peuvent aider l'utilisateur à créer des fichiers de configuration supplémentaires, télécharger d'autres trucs sur le net ou instancier des programmes personnalisés. zc.buildout Le site Web contient un didacticiel vidéo qui explique en détail comment utiliser le buildout et comment l'étendre. Notre projet Bob fait un usage intensif de buildout pour distribuer des packages à usage scientifique. Si vous le souhaitez, veuillez visitez la page suivante qui contient des instructions détaillées pour nos développeurs sur la façon dont ils peuvent configurer leurs packages python afin que d'autres personnes puissent les construire et les installer localement) en utilisant zc.buildout
.
Nous travaillons actuellement pour faciliter la mise en place par les utilisateurs de l'installation du logiciel Python d'une manière indépendante de la plate-forme (en particulier, voir https: // python-packaging-user-guide .readthedocs.org/en/latest/future.html et http://www.python.org/dev/peps/pep-0453/ )
Pour l'instant, le problème avec deux versions concurrentes d'easy_install a été résolu, avec la fourchette concurrente "distribution" étant fusionnée en arrière dans la ligne principale de développement de setuptools.
Les meilleurs conseils actuellement disponibles sur la distribution multiplateforme et l'installation de Python est capturé ici: https://packaging.python.org/