Mais mon interprétation (degré de confiance faible) est que c'est parce que tu as besoin de droits super-utilisateur pour installer ton package pour tous les utilisateurs du système, en référence au wheel du monde BSD, lui même tiré de l'argot "Big wheel" (= gros poisson).
Cette section options.entry_points définit deux exécutables installés par le package, pipinfo et pippin, qui pour cet exemple pointent tous deux vers le module main du code source. Ce sont donc des alias, mais ils auraient aussi bien pu pointer vers des modules différents (tes différents fichiers).
Même si tu restais avec des alias, tu as toujours la méthode Unix/C classique qui marche tout aussi bien en Python, qui consiste à faire varier le comportement de ton programme en fonction du nom sous lequel il a été appelé (récupéré avec les arguments de la ligne de commande).
Tu peux aussi isoler le code commun dans une bibliothèque comme je le fais avec mon package libpnu et le référencer par une dépendance de package :
[options]install_requires=pnu-libpnu
Quand tu n'as pas de dépendances croisées, tu peux aussi faire des méta-paquets qui ne font que faire une collection d'autres paquets comme je le fais pour mon projet PNU.
Je pense que tu devrais trouver ton bonheur avec l'une de ces approches.
Bien sûr, et l'outil dont j'ai parlé, pysec2vuxml, génère justement une entrée VuXML pour tous ceux qui ont une vulnérabilité de sécurité non signalée, ainsi qu'un index permettant de contacter l'ensemble des mainteneurs concernés.
Je mets mainteneur entre guillemets car le terme est souvent inapproprié. Beaucoup de gens (et j'en ai fait partie) créent des ports pour des outils annexes pour pouvoir créer un port pour un de leurs logiciels ou pour un logiciel tiers qui les intéresse, mais ils ne maintiennent plus particulièrement ces ports annexes par la suite. Dans le cas de ports pour des logiciels Python avec des vulnérabilités PYSEC connues, soit il n'y a pas de correctif connu, soit le logiciel source a été abandonné, soit le mainteneur a abandonné l'affaire depuis longtemps !
Tout d'abord un grand merci pour ce chouette article, copieux et bien documenté, et mettant en avant un pan de l'Histoire de notre discipline, ce que j'adore !
En vue du prochain épisode, je voudrais signaler la catégorie quelques-trucs-en-un avec une production personnelle nommée pip-info (ou pippin :-) ) qui, à ce jour, propose un équivalent tout-en-un des commandes "pip list", "pip list --outdated", "pip show" et "pip-audit". J'ai fait ça à l'origine pour explorer ce que je considérais être des bugs de "pip list --outdated", et puis, comme souvent, je me suis laissé emporter… Dans une version non publiée, j'ai travaillé sur les arborescences de dépendances, amont et aval, des packages Python… avec l'idée d'aller jusqu'aux packages système.
Je mentionne ce lien avec le packaging système car dans mon système favori, FreeBSD (mais je pense que c'est pareil dans Linux), on encapsule des outils ou packages Python dans des packages systèmes, sans toujours être à jour des dernières versions disponibles. Du coup, quand on a pour politique d'être à la pointe de la modernité, on souffre de l'absence d'interdépendances entre les outils de gestion de packages systèmes et ceux de packages Python… Je gère ça à la main pour le moment, mais je sens qu'un jour je vais écrire quelque chose pour automatiser ce travail.
Vous êtes peut-être en train de vous dire que c'est un peu extrême de vouloir tout mettre à jour à la fois dans le système et dans Python, mais la réalité c'est que les packages Python systèmes ont parfois pas mal d'écart avec ceux de PyPI (du moins pour les moins courants) et que beaucoup proposent des versions qui ont des problèmes de sécurité connus.
Pour contrôler cela, j'ai écrit un autre outil, pysec2vuxml, qui m'a permis de montrer que sur près de 4000 packages Python encapsulés dans des packages FreeBSD, environ 1 à 2% avaient des problèmes de sécurité non signalés (NB: c'est la même chose avec les systèmes de packaging de plein d'autres langages…). Cet outil me servait du coup à préparer le signalement de ces problèmes de sécurité au niveau système. Je ne sais pas s'il existe un équivalent de cet outil sur Linux, mais je suis à peu près sûr que le problème y est le même.
En complément du complément, je m'aperçois que Lorinda Cherry est probablement l'autrice de la commande prep en parcourant cette entrée dans ses références :
- McMahon, L.E. Cherry, L.L. Morris, R. UNIX Time‐Sharing System : Statistical Text Processing (1978) Bell System Technical Journal, 57 (6), pp. 2137-2154, DOI : 10.1002/j.1538-7305.1978.tb02146.x
Cette commande ayant été abandonnée depuis longtemps, je l'avais backportée, puis réécrite en Python pour voir ce que ça faisait.
Je mets les liens pour ceux qui voudraient eux-aussi s'en faire une idée en mode nécrocomputing…
Pour ceux qui souhaiteraient un complément d'informations historiques sur Unix et les outils de traitement de texte, j'avais écrit il y a 2 ans une petite histoire des "dictionnaires sous Unix" qui donne des détails sur le contexte des Bell Labs à l'époque, l'intérêt pour les applications de traitement de texte, le Writer's workbench (où Lorinda Cherry avait notamment écrit les utilitaires diction et style), etc.
Lorinda était co-autrice de bc et dc avec Robert Morris (senior - le père de l'auteur du ver Internet), et de eqn avec Brian Kernighan.
[^] # Re: oui c'est la foire.
Posté par HubTou (site web personnel) . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 4.
La seule raison officielle que j'aie pu trouver est : parce que newegg était déjà pris :-)
Mais mon interprétation (degré de confiance faible) est que c'est parce que tu as besoin de droits super-utilisateur pour installer ton package pour tous les utilisateurs du système, en référence au wheel du monde BSD, lui même tiré de l'argot "Big wheel" (= gros poisson).
[^] # Re: Merci, j’espère résoudre mon problème !
Posté par HubTou (site web personnel) . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 3.
Si j'ai bien compris ton problème, tu as 4 ou 5 commandes avec des dépendances croisées résultant du split de ton code source.
C'est tout à fait gérable par un package Python.
Dans l'exemple que j'ai donné plus haut, jette un oeil au fichier setup.cfg. Tu y trouveras la section suivante :
Cette section options.entry_points définit deux exécutables installés par le package, pipinfo et pippin, qui pour cet exemple pointent tous deux vers le module main du code source. Ce sont donc des alias, mais ils auraient aussi bien pu pointer vers des modules différents (tes différents fichiers).
Même si tu restais avec des alias, tu as toujours la méthode Unix/C classique qui marche tout aussi bien en Python, qui consiste à faire varier le comportement de ton programme en fonction du nom sous lequel il a été appelé (récupéré avec les arguments de la ligne de commande).
Tu peux aussi isoler le code commun dans une bibliothèque comme je le fais avec mon package libpnu et le référencer par une dépendance de package :
Quand tu n'as pas de dépendances croisées, tu peux aussi faire des méta-paquets qui ne font que faire une collection d'autres paquets comme je le fais pour mon projet PNU.
Je pense que tu devrais trouver ton bonheur avec l'une de ces approches.
[^] # Re: Catégorie quelques-trucs-en-un et liens avec le packaging système
Posté par HubTou (site web personnel) . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 3.
Bien sûr, et l'outil dont j'ai parlé, pysec2vuxml, génère justement une entrée VuXML pour tous ceux qui ont une vulnérabilité de sécurité non signalée, ainsi qu'un index permettant de contacter l'ensemble des mainteneurs concernés.
Je mets mainteneur entre guillemets car le terme est souvent inapproprié. Beaucoup de gens (et j'en ai fait partie) créent des ports pour des outils annexes pour pouvoir créer un port pour un de leurs logiciels ou pour un logiciel tiers qui les intéresse, mais ils ne maintiennent plus particulièrement ces ports annexes par la suite. Dans le cas de ports pour des logiciels Python avec des vulnérabilités PYSEC connues, soit il n'y a pas de correctif connu, soit le logiciel source a été abandonné, soit le mainteneur a abandonné l'affaire depuis longtemps !
# Catégorie quelques-trucs-en-un et liens avec le packaging système
Posté par HubTou (site web personnel) . En réponse à la dépêche L’installation et la distribution de paquets Python (1/4). Évalué à 4.
Tout d'abord un grand merci pour ce chouette article, copieux et bien documenté, et mettant en avant un pan de l'Histoire de notre discipline, ce que j'adore !
En vue du prochain épisode, je voudrais signaler la catégorie quelques-trucs-en-un avec une production personnelle nommée pip-info (ou pippin :-) ) qui, à ce jour, propose un équivalent tout-en-un des commandes "pip list", "pip list --outdated", "pip show" et "pip-audit". J'ai fait ça à l'origine pour explorer ce que je considérais être des bugs de "pip list --outdated", et puis, comme souvent, je me suis laissé emporter… Dans une version non publiée, j'ai travaillé sur les arborescences de dépendances, amont et aval, des packages Python… avec l'idée d'aller jusqu'aux packages système.
Je mentionne ce lien avec le packaging système car dans mon système favori, FreeBSD (mais je pense que c'est pareil dans Linux), on encapsule des outils ou packages Python dans des packages systèmes, sans toujours être à jour des dernières versions disponibles. Du coup, quand on a pour politique d'être à la pointe de la modernité, on souffre de l'absence d'interdépendances entre les outils de gestion de packages systèmes et ceux de packages Python… Je gère ça à la main pour le moment, mais je sens qu'un jour je vais écrire quelque chose pour automatiser ce travail.
Vous êtes peut-être en train de vous dire que c'est un peu extrême de vouloir tout mettre à jour à la fois dans le système et dans Python, mais la réalité c'est que les packages Python systèmes ont parfois pas mal d'écart avec ceux de PyPI (du moins pour les moins courants) et que beaucoup proposent des versions qui ont des problèmes de sécurité connus.
Pour contrôler cela, j'ai écrit un autre outil, pysec2vuxml, qui m'a permis de montrer que sur près de 4000 packages Python encapsulés dans des packages FreeBSD, environ 1 à 2% avaient des problèmes de sécurité non signalés (NB: c'est la même chose avec les systèmes de packaging de plein d'autres langages…). Cet outil me servait du coup à préparer le signalement de ces problèmes de sécurité au niveau système. Je ne sais pas s'il existe un équivalent de cet outil sur Linux, mais je suis à peu près sûr que le problème y est le même.
Voilà. J'ai hâte de lire la suite de l'article !
[^] # Re: En complément du complément sur Unix et les outils de traitement de texte
Posté par HubTou (site web personnel) . En réponse à la dépêche Lorinda Cherry, la programmeuse Unix qui aimait la course automobile et les chiens et ses consœurs. Évalué à 4.
En complément du complément, je m'aperçois que Lorinda Cherry est probablement l'autrice de la commande prep en parcourant cette entrée dans ses références :
- McMahon, L.E. Cherry, L.L. Morris, R. UNIX Time‐Sharing System : Statistical Text Processing (1978) Bell System Technical Journal, 57 (6), pp. 2137-2154, DOI : 10.1002/j.1538-7305.1978.tb02146.x
Cette commande ayant été abandonnée depuis longtemps, je l'avais backportée, puis réécrite en Python pour voir ce que ça faisait.
Je mets les liens pour ceux qui voudraient eux-aussi s'en faire une idée en mode nécrocomputing…
# En complément sur Unix et les outils de traitement de texte
Posté par HubTou (site web personnel) . En réponse à la dépêche Lorinda Cherry, la programmeuse Unix qui aimait la course automobile et les chiens et ses consœurs. Évalué à 4.
Pour ceux qui souhaiteraient un complément d'informations historiques sur Unix et les outils de traitement de texte, j'avais écrit il y a 2 ans une petite histoire des "dictionnaires sous Unix" qui donne des détails sur le contexte des Bell Labs à l'époque, l'intérêt pour les applications de traitement de texte, le Writer's workbench (où Lorinda Cherry avait notamment écrit les utilitaires diction et style), etc.
Lorinda était co-autrice de bc et dc avec Robert Morris (senior - le père de l'auteur du ver Internet), et de eqn avec Brian Kernighan.