PyPI a les versions stables (versions que nous pensons prêtes pour la production). La branche principale que vous avez liée ci-dessus a un support en cours pour Python 3. Une grande quantité de travail a été fait vers le support de Python 3 et il prend forme, mais un bogue Python 3 important a été trouvé et corrigé seulement sur un il y a une semaine (#1054). Plus de tests sont nécessaires avant qu'il puisse être considéré comme prêt pour la production.

Pourquoi ces problèmes sont-ils clos ? Le fichier README indique que _Supervisor est connu pour fonctionner avec Python 2.4 ou une version ultérieure, mais ne fonctionnera sous aucune version de Python 3._, ce qui signifie que #1060 et #1070 ne doivent pas être fermés.

Pourquoi ces problèmes sont-ils clos ? Le README indique que Supervisor est connu pour fonctionner avec Python 2.4 ou version ultérieure, mais ne fonctionnera sous aucune version de Python 3.

Vous citez le README de la version stable actuelle de Supervisor 3 ( fichier ). Le fichier README de cette version indique les exigences de cette version.

La prochaine version majeure, Supervisor 4, inclura la prise en charge de Python 3. Il s'agit de la branche principale de git. Le README de cette version a été mis à jour pour indiquer la prise en charge de Python 3.

Existe-t-il une feuille de route pour la sortie de la version 4 ? Il ne semble y avoir aucun problème ouvert sur Python 3. Existe-t-il un moyen d'aider à tester la branche git actuelle ?

Moi aussi je suis prêt à aider à tester

@tcwalther @palmkevin Merci d'avoir proposé d'aider à tester. Ce serait très utile si vous pouviez essayer d'exercer la branche master sous Python 3 et 2, en essayant autant d'options et de commandes que possible, et en faisant rapport. Vous pouvez faire un rapport dans "J'ai trouvé x bug" ou "Je l'ai utilisé pendant x heures et exercé x fonctionnalités et je n'ai pas trouvé de problème". Les deux seraient utiles.

Plusieurs personnes ont signalé que cela fonctionnait sur Python 3, mais il est clair pour moi d'après les bogues que j'ai trouvés par la suite que ces personnes ne le testaient pas de manière très rigoureuse. Par exemple, #1054 est une fonctionnalité majeure de Supervisor et aurait dû être signalé. J'ai juste commencé à taper les commandes par ordre alphabétique et la première que j'ai essayée n'a pas fonctionné du tout.

Il y a eu beaucoup de progrès vers la prise en charge de Python 3 au cours des derniers mois. Pour le moment, je ne suis au courant d'aucun bogue spécifique à Python 3, c'est pourquoi il n'y en a pas dans le tracker. Cela fonctionne enfin suffisamment pour que j'ai commencé à l'exécuter sous Python 3 maintenant. J'aimerais faire une version compatible avec Python 3. Cependant, les gens dépendent de ce logiciel sur les serveurs de production, il est donc important que nous ayons l'assurance qu'il fonctionne réellement. Les rapports de tests réussis seraient utiles.

Certains tests de base de la branche maître montre qu'il semble « travail » au moins un peu :) testeront pendant un certain temps et d' après tous les problèmes que nous trouvons ici ... (@tcwalther et moi sommes dans la même bande).

Pour seconder @jkp , nous testons cela dans notre équipe au travail (nous sommes dans la même équipe). Nous n'utilisons aucune commande sophistiquée, mais exécutons uniquement supervisord -c some_config_file au premier plan comme point d'entrée dans un conteneur Docker. Nous vous informerons si nous trouvons des problèmes.

@mnaberez IMHO si les tests sont nécessaires plus que le portage du code, il pourrait être utile de publier les versions alpha/beta/rc, donc on n'a pas besoin de récupérer le superviseur de git.

Sommes-nous plus proches d'une sortie ? Nous aimerions beaucoup utiliser Python 3.

Veuillez envisager de publier une version bêta sur PyPI afin que les utilisateurs puissent tester la compatibilité Python3 plus facilement.

Merci beaucoup.

Une pré-version sur PyPI aidera beaucoup, merci.

Veuillez envisager de publier une version bêta sur PyPI afin que les utilisateurs puissent tester la compatibilité Python3 plus facilement.

Vous devriez pouvoir installer la branche master avec pip utilisant une seule commande (voir Support VCS ). Nous apprécierions que vous utilisiez cette méthode, ou un git checkout, pour éviter aux mainteneurs le travail supplémentaire d'empaqueter des versions non stables qui ne seront utilisées que par les testeurs.

D'autres bogues spécifiques à Python 3 ont été signalés et corrigés récemment (par exemple abef0a2be35f4aae4a4edeceadb7a213b729ef8d).

Vous citez le README de la version stable actuelle de Supervisor 3 ( fichier ). Le fichier README de cette version indique les exigences de cette version.

Le README et la documentation en ligne (pour la version stable actuelle) indiquent :

Supervisor est connu pour fonctionner avec Python 2.4 ou version ultérieure, mais ne fonctionnera sous aucune version de Python 3.

Ces mots sont encore un peu trompeurs pour moi (cela m'a fait peur et m'a fait craindre si je devais utiliser Supervisor). Je pensais que Supervisor (comme vs Supervisor 3 ) ne prendrait

@adah1972 Le problème ici est qu'il n'y a pas de classificateurs Python3 sur https://pypi.python.org/pypi/supervisor, donc lorsque les utilisateurs accèdent à PyPI, cela leur dit que Supervisor _only_ s'exécute sur l'ancien Python.

Le problème ici est qu'il n'y a pas de classificateurs Python3 trove sur https://pypi.python.org/pypi/supervisor, donc lorsque les utilisateurs accèdent à PyPI, cela leur dit que Supervisor ne fonctionne que sur Python hérité.

Le projet Supervisor ne publie que des versions stables de PyPI. Il n'y a actuellement pas de version stable de Supervisor prenant en charge Python 3. Des tentatives pour ajouter la prise en charge de Python 3 ont été faites et nous sommes beaucoup plus proches, mais des bogues dans le port Python 3 continuent d'être trouvés. Un autre qui a cassé une fonctionnalité majeure a été trouvé plus tôt ce mois-ci.

Les classificateurs README et Trove que vous voyez sur PyPI sont corrects pour la dernière version stable. Les classificateurs Trove ont été mis à jour dans setup.py pour la branche Python 3 et seront ajoutés à PyPI lorsqu'une version stable de cette version sera publiée.

Je dirais qu'il suffirait de dire :

Supervisor est connu pour fonctionner avec Python 2.4 ou une version ultérieure, mais il ne fonctionne sous aucune version de Python 3.

Cela semble vraiment étrange et déroutant de dire que non .

Salut @mnaberez ,

Je travaille avec @palmkevin sur le même projet. Nous avons téléchargé le superviseur v4.0.0-dev0 et l'avons hébergé sur notre pypiserver privé.
Nous l'utilisons depuis environ 2 mois dans notre environnement de développement et depuis quelques semaines maintenant dans certains environnements de production clients. Nous n'avons rencontré aucun problème jusqu'à présent.

Nous communiquons avec le superviseur via xmlrpc et utilisons les fonctionnalités suivantes :

• fermer
• startProcess
• arrêterProcessus
• rechargerConfig
• getProcessInfo
• getAllProcessInfo
• getState
• tailProcessStdoutLog
• readProcessStdoutLog
• getSupervisorVersion

Sachant cela, j'espère que nous pourrons vous encourager à publier une première version de votre package sur pypi.

@henkesde92 D'où avez-vous obtenu la version 4.0.0-dev0 ? Je ne vois pas qu'il y ait une étiquette ou une branche pour cela.
Utilisez-vous simplement le chef de la branche master ?

Plus de problèmes fonctionnant sur Python 3 ont été trouvés et marqués . Dans au moins un cas (#1178), l'interface Web cesse complètement de fonctionner. Toute aide pour corriger ces problèmes serait appréciée.

@mnaberez Maintenant que https://github.com/Supervisor/supervisor/pull/1187 est fusionné, sommes-nous sur le point d'obtenir une version ? Même un téléchargement bêta/rc nous aiderait grandement,

Cela aiderait à se concentrer sur #1110 qui, je pense, est résolu, mais c'est le seul problème ouvert avec une étiquette ___python 3___ .

Existe-t-il une possibilité de publier une version bêta ou rc du superviseur sur PyPI ? Je travaille sur un projet open source qui utilise intensivement le superviseur (https://github.com/ansible/awx), et nous nous rapprochons du support Python3, et c'est le _un_ élément restant qui nous retient. Si une version était disponible sur PyPI, nous finirions par l'ajouter à notre vaste matrice de test d'intégration où nous déployons et testons notre projet sur une variété de distributions.

Je serais heureux d'aider à creuser dans tous les problèmes ouverts restants (comme
https://github.com/Supervisor/supervisor/issues/1110) qui se rapportent à la prise en charge de py3 et aident à franchir la ligne d'arrivée.

1110 semble également se produire sur l'ancien Python, mais il serait certainement utile de trouver sa cause première.

@mnaberez Pourriez-vous, s'il vous plaît, publier une version bêta ? Cela nous aiderait énormément à tester la prise en charge de Python 3.

@mnaberez ,

Un projet source sur lequel je travaille (https://github.com/ansible/awx) a récemment commencé à tester HEAD de ce référentiel dans nos builds, alors que nous travaillons sur la prise en charge des distributions py3 uniquement. Nous exécutons une suite de tests d'intégration nocturne très approfondie sur plusieurs distributions Linux. Nous utilisons diverses commandes supervisorctl et utilisons également RPC : https://github.com/ansible/awx/blob/devel/tools/docker-compose/supervisor.conf

Jusqu'à présent, nous n'avons remarqué aucune régression dans nos tests d'installations exécutées sous supervision sous Python 3.6.6.

Nous aimerions expédier la prochaine version pointée sur un 4.0.0 bêta plutôt que d' avoir à fourche git spécifique SHA de cette prise en pension.

Nous aimerions livrer la prochaine version pointée vers une version bêta 4.0.0 plutôt que d'avoir à forger un git SHA spécifique de ce référentiel.

Ce projet ne publie pas de versions instables de PyPI ( indiqué ci-dessus ). Veuillez ne pas envoyer de logiciel de production en utilisant une version instable de Supervisor (git sha ou autre). S'il pouvait être utilisé avec un logiciel de production, il serait publié en version stable. Je pense que nous sommes proches mais nous n'y sommes pas encore. Il existe un certain nombre de programmes alternatifs qui font ce que fait Supervisor. Si vous ne pouvez pas utiliser une version stable de Supervisor, je vous recommande de choisir une alternative plutôt que de risquer un environnement de production sur une version instable.

@mnaberez ,

Étant donné qu'il semble y avoir un certain nombre de personnes dans ce fil qui font _exactement_ cela en production (et ne signalent aucun problème), et qu'il n'y a pas de problèmes ouverts _notables_ liés à python3 dans le tracker (il y a https://github.com/Supervisor /supervisor/issues/1110, bien qu'il semble difficile à reproduire, de faible gravité et spécifique à l'utilisation de supervisorctl tail ), à quel moment considéreriez-vous le superviseur stable en python3 et digne d'une version ? Y a-t-il un ensemble tangible de critères qui freinent cela ?

Étant donné qu'il semble y avoir un certain nombre de personnes dans ce fil qui font exactement cela en production (et ne signalent aucun problème)

Il y a eu des gens qui utilisent Supervisor sur Python 3 depuis 2014. Pendant presque tout le temps depuis, certains ont insisté assez vocalement sur ce traqueur de problèmes pour qu'il fonctionne bien. L'un des plus surprenants pour moi était le #1054. Après des années de réclamations, cela a fonctionné, une commande entière a été complètement interrompue pour la configuration par défaut. Il y avait des problèmes similaires avec les fonctionnalités de base comme la journalisation étant également très interrompue après des années de rapports de réussite. Ainsi, bien que j'apprécie et écoute les rapports de réussite, je ne les pèserai peut-être pas autant que je le ferais si je n'avais pas eu ces expériences.

et qu'il n'y a pas de problèmes ouverts notables liés à python3 dans le tracker (il y a le #1110, bien qu'il semble difficile à reproduire, de faible gravité et spécifique à l'utilisation de la queue superviseurctl)

Le suivi des problèmes n'a pour la plupart été exempt de bogues Python 3 que pendant une courte période, et il est possible que le bogue du descripteur de fichier défectueux ne soit qu'une manifestation d'un problème plus important. Je pense au moins qu'il faut plus d'investigation avant que sa portée ou sa gravité puisse être comprise. Il y a aussi un tas de problèmes étiquetés "aide recherchée", et j'aimerais les examiner pour m'assurer qu'il s'agit de problèmes existants et non causés par des modifications apportées au maître, car certains des retraçages sur ceux-ci proviennent du maître.

à quel point ce que vous considérez comme superviseur stable en python3 et digne d'une version ? Y a-t-il un ensemble tangible de critères qui freinent cela ?

Je vais essayer de revoir les problèmes mentionnés ci-dessus (mauvais descripteur de fichier et aide recherchée), et également faire des tests plus rigoureux, avant qu'il ne soit supprimé. Je ne suis pas le seul committer capable de sortir ce logiciel, mais je suis le plus actif ces derniers temps. Je suis l'un des principaux auteurs des correctifs Python 3 sur ce projet - je veux moi-même une version stable et compatible avec Python 3. Dans le même temps, je veux être sûr que cela ne fera pas tomber un tas de sites Web de production ou ne générera pas une tempête de nouveaux problèmes de support. Comme je l'ai dit plus haut, je pense que c'est proche, mais je ne recommanderais pas d'exécuter une version instable de Supervisor en production.

alors il peut être publié en version bêta (4.0.0b) sur PyPI et même marqué comme Python 3 uniquement en utilisant le spécificateur de version PEP 440

setup(
    ...
    python_requires='>=3',
    ...
)

de cette façon:

• toutes les personnes souhaitant utiliser le superviseur dans le projet Python 3 y accéderont beaucoup plus facilement, alors qu'il sera toujours marqué comme étant considéré comme instable (en fait, pipenv pour un, n'installera pas la version bêta à moins qu'il ne soit explicitement configuré pour)
• plus d'utilisateurs (python 3 crowd) -> plus de fonctionnalités testées -> plus de confiance dans la prise en charge de Python 3
• les utilisateurs actuels (Python 2) ne seront pas affectés négativement

Personnellement, je pense qu'il devrait être plus rapide de trier les problèmes signalés par les nouveaux utilisateurs de Python 3 que d'attendre que le propriétaire/les contributeurs du projet trouvent suffisamment de temps pour réfléchir et tester chaque scénario possible.

Je voudrais également noter que vu la fermeture de Python 2 EoL (1er janvier 2020), la prise en charge de Python 3 n'est plus une option, mais une exigence pour maintenir ce projet en vie, c'est pourquoi je propose cette solution.

La couverture actuelle est à 89%: https://travis-ci.org/Supervisor/supervisor/jobs/476482824 cognant à 95-99% pourrait vous faire sentir plus à l' aise pour faire une nouvelle version? :pensée:

Les correctifs pour ajouter une couverture de test sont les bienvenus et contribueraient à renforcer la confiance.

Désespéré pour une version de support Python 3, s'il vous plaît... :)

La documentation ne devrait-elle pas être mise à jour pour dire qu'elle n'est pas encore disponible sur python 3 ? ou modifié pour montrer comment l'installer sur un système python 3 ?
impossible d'installer le superviseur sur python 3 #1205

La documentation ne devrait-elle pas être mise à jour pour dire qu'elle n'est pas encore disponible sur python 3 ?

La documentation de la version actuelle (3.3.5), qui est publiée sur superviseurd.org , dit déjà ce qui suit :

http://supervisord.org/introduction.html#platform -requirements
"Supervisor est connu pour fonctionner avec Python 2.4 ou une version ultérieure, mais ne fonctionnera sous aucune version de Python 3."

@henkesde92 D'où avez-vous obtenu la version 4.0.0-dev0 ? Je ne vois pas qu'il y ait une étiquette ou une branche pour cela.
Utilisez-vous simplement le chef de la branche master ?

@stevecj Il n'y a pas de balise ou de branche, c'est sur master, mais le numéro de version vient de setup.py qui à son tour le lit à partir de supervisor/version.txt .

Clôturer ce numéro... Cela fait deux ans sans presque aucun progrès.

Avec seulement 295 jours avant la fin de la vie de Python 2, ce port n'aura pas lieu à temps.

@cclauss Peut-être qu'il n'y a pas de progrès car cela fonctionne déjà ? Je ne comprends pas vraiment pourquoi il n'est pas simplement emballé pour Python 3 et laisse les utilisateurs l'utiliser et signaler les problèmes au fur et à mesure qu'ils sont découverts ? C'est sûrement l'un des meilleurs moyens de faire progresser les logiciels open source ? Laisser le projet mourir parce que personne n'a la confiance nécessaire pour publier une version Python 3 semble précieux. Beaucoup de travail acharné a évidemment été consacré à ce projet.

FWIW, j'utilise "4.0.0-dev0" avec Python 3.5 depuis près de 12 mois sans aucun problème pour moi. Cependant, j'admets que je ne teste pas toutes les fonctionnalités, mais cela semble assez bon pour au moins laisser la communauté commencer à l'utiliser correctement.

@mnaberez @cclauss Pourquoi vous

Celui-ci devrait également être rouvert.

Réouverture car il semble toujours y avoir un intérêt important pour cette question.

Je dirais de sortir de la case « nous ne publions que des versions stables » et de publier une version alpha ou bêta publique sur pypi pour la transition py2 -> py3 pour le bien de ce logiciel fantastique.

De cette façon, vous laissez les utilisateurs décider d'utiliser des versions alpha ou bêta et tout le monde sait ce que signifie cette terminologie.

Les tests seront beaucoup plus faciles pour de nombreux utilisateurs et des progrès peuvent être réalisés à court terme lorsque des problèmes sont ajoutés.

De cette façon, vous laissez les utilisateurs décider d'utiliser des versions alpha ou bêta et tout le monde sait ce que signifie cette terminologie.

Pendant la majeure partie de sa vie, ce projet a utilisé un schéma de version déroutant. C'était en grande partie avant mon implication dans l'emballage donc je ne peux pas répondre pourquoi. Les versions stables avaient des noms alpha/bêta étranges comme "3.0a3" ou "3.0b2". Peut-être qu'ils étaient initialement destinés à être alpha/bêta, mais ils ont duré des années et étaient stables - ils n'avaient pas de problèmes importants et aucune rupture de BC entre eux dont je me souvienne. Les versions portant ces noms ont même été empaquetées par les principales distributions comme stables. Cette très longue histoire rend difficile pour nous maintenant de communiquer efficacement les versions non stables réelles aux utilisateurs existants.

@mnaberez ,

Il semble que le dernier exemple de cela (du moins, d'après ce que je peux dire dans PyPI) était https://pypi.org/project/supervisor/3.0b2/

... c'était il y a presque 6 ans maintenant. Cela coïncide également avec le passage de superviseur2 à superviseur3, de sorte que la notion de pré-versions est un schéma de version majeur avec lequel les utilisateurs devraient être habitués, historiquement.

Cela pourrait - il éventuellement être traitée par une liste de diffusion post expliquant qu'une nouvelle version alpha / beta / rc a été publié avec le soutien officiel pour python3 Peut - être appeler de façon très explicite en quelque sorte à (y compris des instructions sur la façon de signaler tout problème trouvé?) Http: //supervisord.org?

Il me semble qu'il y a un certain nombre de personnes dans ce fil qui expédient _déjà_ des logiciels de production en utilisant 4.0.0dev . Les distributions l'emballent même à partir de (je suppose) HEAD .

https://koji.fedoraproject.org/koji/buildinfo?buildID=1203704

En tant que mainteneur de packages logiciels open source moi-même, je pense que cette situation serait beaucoup moins souhaitable que de simplement distribuer une pré-version, d'entendre directement les utilisateurs et de corriger les bogues qui existent.

@mnaberez Étant donné que la principale préoccupation est que les versions stables étaient postfixées avec a ou b , pourriez-vous s'il vous plaît utiliser rc pour les pré-versions actuelles ?

Encore une fois, beaucoup de gens sont bloqués là-dessus

... c'était il y a presque 6 ans maintenant. Cela coïncide également avec le passage de superviseur2 à superviseur3, de sorte que la notion de pré-versions est un schéma de version majeur avec lequel les utilisateurs devraient être habitués, historiquement.

Il a utilisé l'étrange schéma de version a/b pour toutes les versions d'environ 2007-2011. Il n'y avait pas que des pré-sorties.

Peut-être que la release candidate rc serait mieux ? Encore une fois, 2007 - 2011 était il y a plus de 8 ans.

@mnaberez La version actuelle de master fonctionne assez bien avec Python3, la communauté a juste besoin d'une version, même si elle n'est pas parfaite. Cela a tout son sens si le bogue persiste, cela apparaît également dans Python2, comme le soulignent certaines personnes.

Tous mes collègues membres de la communauté Plone et je suppose que ceux de Pyramid sont également impatients de l'avoir. S'il vous plaît, pouvez-vous le libérer? Un alpha ferait parfaitement l'affaire.
Merci beaucoup!

/cc @mcdonc @tseaver @stevepiercy @zupo @gforcada @pbauer @jensens @tisto

Il n'y aura jamais de perfection dans le logiciel. Le superviseur est à proximité, bien qu'il y ait des bogues ouverts dans le suivi des problèmes. Pour faire avancer les choses, il serait bon de marquer les problèmes à l'aide d'une étiquette supplémentaire telle que « bloqueur de version » (avec l'« aide recherchée » existante ?) avec des compétences de développement, l'utilisation de superviseur peut résoudre les problèmes et fournir des correctifs.

Actuellement, le problème majeur pour la plupart des gens n'est pas la stabilité, mais l'absence de la version Python 3. Une version est différente de l'installation via VCS et peut être conditionnée et distribuée différemment, s'intégrant dans les workflows d'exploitation actuels. Donc, même si je me répète ici, cette incertitude est un problème majeur.

@sneridagh les seuls mainteneurs sur PyPI sont @mcdonc et @mnaberez. D'autres ne peuvent rien faire pour libérer Supervisor sur PyPI.

Les principaux développeurs de Pyramid publient des versions alpha et bêta , et cela fonctionne bien pour nous. Nous communiquons les versions via les canaux habituels : liste de diffusion , Twitter et README.

Je ne vois aucun problème à faire de même avec Supervisor, et je pense que ce serait bénéfique pour son développement ultérieur. Zut, il pourrait même y avoir un autre mainteneur qui se cache pour partager le fardeau.

Même nous avons essayé d'utiliser la version principale actuelle. Et ça marche très bien.
J'espère que cela pourra être publié en tant que package bêta, car nous pouvons l'utiliser directement plutôt que de forger le référentiel et de l'installer manuellement. Je vais bientôt héberger ce package sur un nouveau référentiel PIP. Beaucoup d'entre vous peuvent extraire le paquet pip à partir de là lui-même. Sera mis à jour ici bientôt.

Je vais bientôt héberger ce package sur un nouveau référentiel PIP. Beaucoup d'entre vous peuvent extraire le paquet pip à partir de là lui-même. Sera mis à jour ici bientôt.

Une recherche rapide de PyPI montre qu'au moins une personne l'a déjà fait :

https://pypi.org/project/supervisor-lrn/

Remarque : l'auteur de ce package n'est pas impliqué dans le projet Supervisor. Je n'ai pas téléchargé ou vérifié ce package.

Clôture au profit du fork compatible Python 3 https://pypi.org/project/supervisor-lrn/

@cclauss sérieusement ?

D'accord, c'est dommage mais après plus de 10 ans d'utilisation de superviseur, nous allons passer à pm2 ou systemd.

A bientôt et merci pour tous les poissons.

Je ne comprends vraiment pas la façon dont les mainteneurs du projet ont décidé de
allez-y. C'est vraiment dommage, peu importe. La communauté demande seulement
pour une version bêta pour aider à tester et finaliser la prise en charge de python 3. Au lieu,
vous dirigez les gens vers une fourchette.
Je vais aussi passer à autre chose.

Le dim. 24 mars 2019, 14:44 Víctor Fernández de Alba, <
[email protected]> a écrit :

@cclauss https://github.com/cclauss sérieusement ?

D'accord, c'est dommage mais après plus de 10 ans d'utilisation de superviseur, nous allons
passer pour utiliser pm2 ou systemd.

A bientôt et merci pour tous les poissons.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Supervisor/supervisor/issues/1060#issuecomment-475960800 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAGU8E33aSZ3ocMQoP7evXh7WWEq4Gv_ks5vZ4E1gaJpZM4SInJR
.

Veuillez arrêter de fermer le problème @cclauss. Il y a clairement un intérêt de la part de la communauté et de @mnaberez.

@cclauss sérieusement ?

D'accord, c'est dommage mais après plus de 10 ans d'utilisation de superviseur, nous allons passer à pm2 ou systemd.

@cclauss , la personne qui ferme ce ticket à plusieurs reprises, ne fait pas partie du projet Supervisor. Il est capable de le fermer parce qu'il l'a ouvert à l'origine.

Puisqu'il y a encore une discussion active ici, je vais la rouvrir (encore).

@mnaberez ok, ça a causé un peu de confusion, je pensais qu'il était en charge aussi. Peut-être devrions-nous passer à un autre problème.

Quel est le bloqueur qui vous retient alors pour la sortie ?

@mnaberez Et la même discussion dans ce ticket s'est déjà répétée plusieurs fois et ne va pas dans une direction (positive).

Peut-être que vous et d'autres mainteneurs pourriez expliquer ou reconsidérer votre point de vue sur ce problème et le clore ensuite ?

Plusieurs utilisateurs et autres mainteneurs d'OSS ont déjà demandé ici une version officielle de rc. Maintenant, quelqu'un qui n'est pas lié au projet du superviseur l'a fait. Je ne pense pas que cela soit bénéfique pour le projet Supervisor, mais compréhensible si vous ne le faites pas.

C'est vraiment dommage, peu importe. La communauté ne demande qu'une version bêta pour aider à tester et finaliser la prise en charge de python 3. Au lieu de cela, vous dirigez les gens vers une fourchette.

Veuillez noter que j'ai signalé le package tiers existant uniquement en réponse à un autre utilisateur commentant la création d'un package . Mon intention était seulement de sauver cette personne de faire un travail qui avait déjà été fait.

Peut-être que vous et d'autres mainteneurs pourriez expliquer ou reconsidérer votre point de vue sur ce problème et le clore ensuite ?

J'ai l'intention de publier un package officiel Supervisor 4.0.0 avec prise en charge de Python 3 d'ici 2 semaines. Il est peu probable que la version s'appelle alpha/beta pour les raisons historiques mentionnées ci-dessus, mais peut être appelée rc comme suggéré par @ofek , @ryanpetrello et d'autres. Cependant, cela fait plusieurs mois que j'ai fait les commentaires sur la stabilité ci-dessus, et aucun nouveau problème Python 3 n'a été signalé depuis. Je l'ai également utilisé pendant cette période et je n'ai pas eu de nouveaux problèmes. Compte tenu de tout cela et du nombre de personnes déclarant que cela fonctionne pour eux, il peut simplement s'appeler 4.0.0. Je fermerai ce ticket lorsqu'il sera publié sur PyPI.

Quel est le bloqueur qui vous retient alors pour la sortie ?

Il n'y a actuellement pas de bloqueur pour cela, à part que j'aimerais d'abord créer une version 3.4.0 sur laquelle j'ai déjà commencé. J'ai l'intention de le faire la semaine prochaine, et 4.0.0 la semaine suivante.

Veuillez garder cela ouvert, nos projets ont vraiment besoin que cela se produise aussi.

Supervisor 4.0.0 (package PyPI ; prend en charge Python 3.4+ et 2.7)