Les packages Python sont fréquemment hébergés dans de nombreux référentiels de distribution. Après avoir lu ce didacticiel, en particulier la section intitulée "Voulez-vous vraiment faire cela"? J'ai évité d'utiliser pip et j'ai préféré utiliser le référentiel système, ne recourant à pip que lorsque j'ai besoin d'installer un package qui ne se trouve pas dans le référentiel.

Cependant, comme il s'agit d'une méthode d'installation incohérente, serait-il préférable de n'utiliser que pip? Quels sont les avantages / les inconvénients d'utiliser pip sur le propre référentiel du système pour les packages disponibles aux deux endroits?

Le lien que j'ai inclus les états

L'avantage de toujours utiliser les packages Debian / NeuroDebian standard est que les packages sont soigneusement testés pour être compatibles entre eux. Les paquets Debian enregistrent les dépendances avec d'autres bibliothèques afin que vous obteniez toujours les bibliothèques dont vous avez besoin dans le cadre de l'installation.

J'utilise arch. Est-ce le cas avec d'autres systèmes de gestion de paquets en plus d'apt?

Le plus gros inconvénient que j'observe en utilisant pippour installer des modules Python sur votre système, que ce soit en tant que modules système ou en tant que modules utilisateur, est que le système de gestion des packages de votre distribution ne les connaîtra pas. Cela signifie qu'ils ne seront pas utilisés pour tout autre paquet qui en a besoin et que vous voudrez peut-être installer à l'avenir (ou qui pourrait commencer à utiliser l'un de ces modules après une mise à niveau); vous serez alors finir avec les deux pip- et les versions gérées la distribution des modules, ce qui peut causer des problèmes (je courais dans une autre instance de cette récemment). Donc, votre question finit par être une proposition tout ou rien: si vous utilisez uniquementpip pour les modules Python, vous ne pouvez plus utiliser le gestionnaire de paquets de votre distribution pour tout ce qui veut utiliser un module Python ...

Le conseil général donné dans la page à laquelle vous avez lié est très bon: essayez d'utiliser les packages de votre distribution autant que possible, utilisez uniquement pippour les modules qui ne sont pas packagés, et lorsque vous le faites, faites-le dans votre configuration utilisateur et non dans le système- large. Utilisez autant que possible des environnements virtuels, notamment pour le développement de modules. Surtout sur Arch, vous ne devriez pas rencontrer de problèmes causés par des modules plus anciens; même sur les distributions où cela peut être un problème, les environnements virtuels le traitent assez facilement.

Il vaut toujours la peine de considérer que la bibliothèque d'une distribution et les packages de modules sont conditionnés principalement pour l'utilisation d'autres packages dans la distribution; les avoir autour est un bon effet secondaire pour le développement en utilisant ces bibliothèques et modules, mais ce n'est pas le cas d'utilisation principal.

TL; DR

• utiliser pip(+ virtualenv) pour des trucs (libs, frameworks, peut-être des outils de développement) vos projets (que vous développez) utilisent
• utiliser le gestionnaire de packages pour les applications que vous utilisez (en tant qu'utilisateur final)

Dépendances de développement

Si vous développez un logiciel en Python, vous voudrez l'utiliser pippour toutes les dépendances du projet, qu'il s'agisse de dépendances d'exécution, de dépendances au moment de la construction ou de choses nécessaires pour les tests automatisés et les vérifications de conformité automatisées (linter, style checker, static type checker ...)

Il y a plusieurs raisons à cela:

• Cela vous permet d'utiliser virtualenv (directement ou via virtualenvwrapper ou pipenv ou d'autres moyens) pour séparer les dépendances des différents projets les uns des autres et pour isoler les applications python que vous utilisez "en production" (en tant qu'utilisateur) de tous les shenanigans exotiques (ou même des incompatibilités) qui peuvent se poursuivre en cours de développement.
• Cela vous permet de suivre toutes les dépendances d'un projet dans un fichier requirements.txt(si votre projet est une application) ou setup.py(si votre projet est une bibliothèque ou un framework). Cela peut être vérifié dans le contrôle de révision (par exemple Git) avec le code source, afin que vous sachiez toujours quelle version de votre code dépend de quelles versions de vos dépendances.
• Ce qui précède permet à d'autres développeurs de collaborer sur votre projet même s'ils n'utilisent pas la même distribution Linux ou même pas le même système d'exploitation (si les dépendances utilisées sont également disponibles sur Mac et Windows ou tout ce qu'ils utilisent, c'est-à-dire)
• Vous ne voulez pas que les mises à jour automatiques du gestionnaire de packages de votre système d'exploitation cassent votre code. Vous devez mettre à jour vos dépendances, mais vous devez le faire consciemment et au moment que vous choisissez, afin d'être prêt à corriger votre code ou à annuler la mise à jour. (Ce qui est facile si vous suivez la déclaration de dépendance complète dans votre système de contrôle des révisions, avec votre code.)

Si vous pensez que vous devez séparer les dépendances directes et indirectes (ou faire la distinction entre la plage de versions acceptable pour une dépendance et la version réelle utilisée, cf. "épinglage de version"), regardez dans pip-tools et / ou pipenv. Cela vous permettra également de faire la distinction entre les dépendances de génération et de test. (La distinction entre les dépendances de génération et d'exécution peut probablement être encodée dans setup.py)

Applications que vous utilisez

Pour les choses que vous utilisez comme application normale et qui se trouvent être écrites en Python, préférez le gestionnaire de packages de votre système d'exploitation. Il s'assurera qu'il reste raisonnablement à jour et compatible avec d'autres choses installées par le gestionnaire de paquets. La plupart des distributions Linux affirmeront également qu'elles ne distribuent aucun malware.

Si quelque chose dont vous avez besoin n'est pas disponible dans le référentiel de packages par défaut de votre distribution, vous pouvez consulter des dépôts de packages supplémentaires (par exemple, le tableau de bord des distributions basées sur deb) ou utiliser de piptoute façon. Dans ce dernier cas, utilisez --userpour installer dans la maison de votre utilisateur au lieu de l'ensemble du système, de sorte que vous êtes moins susceptible de casser votre installation Python. (Pour les choses dont vous n'avez besoin que temporairement ou rarement, vous pouvez même utiliser un virtualenv.)

Une autre raison d'aller avec le gestionnaire de paquets est que les mises à jour seront automatiquement appliquées, ce qui est essentiel pour la sécurité. Pensez que si le paquet de beans utilisé par Equifax avait été mis à jour automatiquement via yum-cron-security, le piratage ne s'est peut-être pas produit.

Sur ma boîte de développement personnelle, j'utilise Pip, dans prod j'utilise des packages.

Si nous parlons d'installer des packages python à utiliser dans le code que vous écrivez, utilisez pip.

Pour chaque projet sur lequel vous travaillez, créez un environnement virtuel, puis utilisez uniquement pip pour installer les éléments dont ce projet a besoin. De cette façon, vous installez toutes les bibliothèques que vous utilisez de manière cohérente, elles sont contenues et n'interfèrent pas avec tout ce que vous installez via votre gestionnaire de packages.

Si vous prévoyez de publier du code python, vous ajouterez généralement un setup.pyou requirements.txtà votre projet, ce qui permettra à pip d'obtenir automatiquement toutes ses dépendances. Vous permettant de créer ou de recréer facilement un environnement virtuel pour ce projet.

Sommaire

Il existe trois catégories générales de modules avec lesquels vous traitez:

1. Ces programmes de support installés pour tous les utilisateurs avec le système de package OS. (Cela peut même inclure des outils et des bibliothèques utilisés par des personnes programmant en Python; voir ci-dessous.) Pour ceux-ci, vous utilisez les packages du système d'exploitation où vous le pouvez et pipinstallez-les dans les répertoires système si nécessaire.
2. Ces programmes de support installés par un utilisateur particulier uniquement pour son propre usage, et aussi pour certains aspects de son utilisation "quotidienne" de Python comme langage de script. Pour cela, elle utilise pip --user, peut-être pyenv ou pythonz , et des outils et tactiques similaires.
3. Ceux qui soutiennent le développement et l'utilisation d'une application spécifique. Pour cela, vous utilisez virtualenv(ou un outil similaire).

Ici, chaque niveau peut également bénéficier de l'assistance d'un niveau précédent. Par exemple, notre utilisateur dans (2) peut s'appuyer sur un interpréteur Python installé via des packages OS.

Entrer dans cela un peu plus en détail:

Programmes et packages système

Les programmes écrits en Python que vous voulez "simplement exécuter" sont faciles: utilisez simplement les outils d'installation du système d'exploitation et laissez-les apporter tout ce dont ils ont besoin; ce n'est pas différent d'un programme non Python. Cela est susceptible d'apporter des outils / bibliothèques Python (tels que l'interpréteur Python lui-même!) Sur lesquels les utilisateurs de votre machine peuvent commencer à compter; ce n'est pas un problème tant qu'ils comprennent la dépendance et, idéalement, connaissent des moyens alternatifs pour la gérer sur les hôtes qui ne fournissent pas ces dépendances.

Un exemple simple et courant d'une telle dépendance est certains de mes scripts personnels ~/.local/bin/qui commencent par #!/usr/bin/env python. Celles-ci fonctionneront correctement (tant qu'elles s'exécutent sous Python 2) sur RH / CentOS 7 et la plupart (mais pas toutes) des installations Ubuntu; ils ne seront pas sous une installation Debian de base ou sous Windows. Tout comme je n'aime pas mon environnement personnel ayant beaucoup de dépendances sur les packages de système d'exploitation (je travaille sur un certain nombre de systèmes d'exploitation différents), quelque chose comme ça, je le trouve assez acceptable; mon plan de sauvegarde sur les rares hôtes qui n'ont pas de système Python et ne peuvent pas en obtenir un est d'utiliser un système utilisateur comme décrit ci-dessous.

Les personnes utilisant un interpréteur python système dépendent également généralement du système pip3. C'est à peu près là que je trace habituellement la ligne sur mes dépendances système; tout de l' virtualenvavant je m'occupe de moi-même. (Par exemple, mon script standard activate repose sur tout pip3ou pipest sur le chemin, mais télécharge sa propre copie virtualenvpour amorcer l'environnement virtuel , il est la création.

Cela dit, il y a probablement des circonstances où il est tout à fait raisonnable de rendre plus disponible un environnement de développement. Vous pouvez avoir des interfaces Python dans des packages complexes (tels qu'un SGBD) où vous souhaitez utiliser la version système de cela et vous pensez qu'il est préférable de laisser également le système choisir le code de bibliothèque Python particulier que vous utiliserez pour lui parler. Ou vous pouvez déployer de nombreux hôtes avec un environnement de développement de base pour une classe Python, et trouver plus facile à automatiser avec des packages système standard.

Programmes et packages utilisateur "au jour le jour"

Les utilisateurs peuvent avoir des bibliothèques ou des programmes Python qui ne s'intègrent pas bien dans un environnement virtuel parce qu'ils veulent aider à créer des environnements virtuels en premier lieu (par exemple, virtualenvwrapper ) ou ce sont des choses que vous utilisez couramment depuis la ligne de commande même lorsque faire du travail non-Python. Même s'ils ont la possibilité d'installer des versions système de ceux-ci, ils peuvent se sentir plus à l'aise d'installer les leurs (par exemple, parce qu'ils veulent utiliser la dernière version de l'outil et ses dépendances).

C'est généralement pip --userce que les gens vont utiliser pour cela, bien que certaines dépendances, telles que l'interpréteur Python lui-même, nécessitent un peu plus que cela. pyenv et pythonz sont utiles pour construire des interprètes personnels (qu'ils soient installés ~/.local/binpour être l'interpréteur par défaut ou autre), et bien sûr, on peut toujours simplement construire "à la main" à partir des sources si les bibliothèques de développement sont disponibles.

J'essaie de garder le strict minimum installé ici: virtualenvwrapper (parce que je l'utilise constamment) et peut-être la dernière version de pip. J'essaie d'éviter les dépendances en dehors de la bibliothèque standard ou sur Python 3 pour les scripts personnels que j'écris pour être utilisés sur de nombreux hôtes. (Bien que nous verrons combien de temps je peux tenir avec cela alors que je déplace de plus en plus de ces scripts personnels vers Python.)

Environnements de développement d'applications et d'exécution distincts

C'est la chose virtualenv habituelle. Pour le développement, vous devez presque toujours utiliser un virtualenv pour vous assurer que vous n'utilisez pas les dépendances du système, ou souvent plus d'un pour tester différentes versions de Python.

Ces environnements virtuels conviennent également aux applications comportant de nombreuses dépendances où vous souhaitez éviter de polluer votre environnement utilisateur. Par exemple, j'ai généralement mis en place un virtualenv pour exécuter les blocs-notes Jupyter et autres.