Psutil: Assistance Cygwin

_De [email protected] le 19 mars 2010 18:21:45_

I looked briefly at this and it appears to be more complex than I had initially
hoped. Cygwin acts like a POSIX environment, but the system level code still needs to
be Windows-specific. Unfortunately this means that most of the code is similar to the
Windows codebase, but that the Cygwin version of Python doesn't know about things
like PyErr_SetFromWindowsErr which we use all over the place. Conversely, the /proc
system and sysctl() don't appear to be available under Cygwin so we can't use the
code from other unix-like systems. 

It's likely we'd need a separate cygwin C module specific to working with Cygwin,
based on the Windows code but with workarounds for things like
PyErr_SetFromWindowsErr() and any other issues that crop up. Opening this ticket as
an enhancement for a placeholder if/when we have a chance to look at this more in depth.

_De [email protected] le 12 mai 2010 09:29:40_

Issue 87 has been merged into this issue.

_De g.rodola le 19 juin 2010 11:14:39_

I'm closing this out for now as it's unlikely we'll find time to look into this in the near future.

Statut : WontFix

Accepteriez-vous un correctif pour ajouter le support Cygwin ?

Je dois avouer que je ne l'ai jamais utilisé et que je n'y connais pas grand chose. Que faudrait-il pour ajouter un support ? Quels avantages cela apporterait-il exactement (par exemple, pourquoi voudriez-vous utiliser psutil de cygwin) ?

Je dois avouer que je ne l'ai jamais utilisé et que je n'y connais pas grand chose.

J'en connais une quantité décente - j'ai passé un certain temps (plus que je ne voudrais l'admettre) dans ses internes.

Que faudrait-il pour ajouter un support ?

D'après mes premières expériences, le moyen le plus simple d'ajouter un support serait de l'ajouter explicitement en tant que plate-forme. C'est trop différent de Linux, ou de Windows ordinaire, pour essayer de le prendre en charge dans les modules Windows ou Linux existants spécifiques à la plate-forme. Cependant, cela réutiliserait une quantité décente de code des deux, ce qui pourrait entraîner (espérons-le _petit_) une quantité de refactorisation.

Heureusement, il n'y aurait pas besoin d'écrire beaucoup de nouveau code. La plupart des méthodes du module Linux fonctionnent - celles qui ne peuvent pas fonctionner avec le code existant du module Windows. C'est juste une question de tirer les bons morceaux aux bons endroits.

De plus, une configuration devrait être ajoutée aux versions AppVeyor qui incluent Cygwin. Je n'ai pas encore essayé d'utiliser Cygwin dans AppVeyor, mais c'est quelque chose sur lequel je travaille.

Quels avantages cela apporterait-il exactement (par exemple, pourquoi voudriez-vous utiliser psutil de cygwin) ?

Les mêmes avantages que psutil sur n'importe quelle autre plate-forme :)

Ok, pour être moins désinvolte, ma principale motivation est de travailler sur SageMath (par exemple https://trac.sagemath.org/ticket/21598). Je travaille à faire fonctionner Sage sur Windows, qui pendant un certain temps au moins continuera à nécessiter Cygwin. Sage est en train de passer à psutil pour toutes les fonctionnalités liées à l'inspection des processus (un mouvement que j'ai fortement soutenu !).

Cela dit, je pense que Cygwin est toujours une plate-forme utile pour le support en général, si j'ajoute un module de support pour cela, je suis prêt à le maintenir.

Merci pour l'info. OK, si tu veux y aller, tu as ma bénédiction. Avez-vous déjà une idée d'où vous pourriez commencer? Puis-je vous aider de quelque manière que ce soit ?

si j'ajoute un module de support pour cela, je suis prêt à le maintenir

C'est encourageant car il y a déjà beaucoup de plates-formes à tester et à garder sous contrôle. Ajouter cygwin à appveyor CI (en supposant que cela soit possible) serait formidable dans ce sens.
Dans le cadre de ce travail, je vous demanderais de mettre à jour les documents INSTALL / DEVGUIDE décrivant comment configurer / installer psutil sur cygwin (car je ne sais pas fondamentalement =)).

@giampaolo Merci pour votre bénédiction - cela seul est d'une grande aide; savoir que si je peux faire en sorte que cela fonctionne à votre satisfaction, je n'aurai pas à entretenir une fourchette pour toujours est encourageant. Je vous ferai savoir si j'ai des questions.

En ce qui concerne la configuration, cela ne nécessite pas grand-chose au-delà de ce qui existe déjà pour Linux, bien qu'il soit nécessaire de documenter les packages nécessaires dans Cygwin. Au-delà de cela, je viens de créer un virtualenv et d'exécuter make setup-dev-env et c'est à peu près tout ce qui est nécessaire.

Juste pour mettre à jour, j'ai en fait presque terminé un prototype de port Cygwin de psutil. J'y ai travaillé par intermittence au cours des derniers mois. Le seul problème en ce moment est que j'essaie de faire passer les tests sur AppVeyor. Restez à l'écoute...

@embray ça a l'air cool; Je serais très intéressé de voir le support de cygwin pour psutil. Y a-t-il des fonctionnalités que vous n'avez pas pu implémenter ? C'est quoi la "bêta" ? Faites-moi savoir si je peux aider de quelque façon que ce soit.

@giampaolo Tous les tests passent sur Python 2 et 3 (sauf sur AppVeyor où j'ai encore quelques problèmes, notamment avec Python 3, pour une raison quelconque).

Il y a quelques morceaux de fonctionnalités qui ne fonctionnent pas/ne peuvent pas fonctionner. Plus particulièrement, la lecture de l'environnement des processus arbitraires ne fonctionne pas (ou du moins n'a pas fonctionné, ce qui m'a conduit à soumettre un correctif, maintenant accepté, à Cygwin pour prendre en charge /proc/<pid>/environ . Donc en fait cette fonctionnalité sera disponible avec les versions plus récentes de Cygwin. ) Je travaille également par intermittence sur un autre correctif pour Cygwin pour prendre en charge plus /proc/net/ points /proc/net/ , ce qui rendra les composants réseau beaucoup plus faciles, mais je ne sais pas combien de temps cela prendra prendre. En attendant, il y a beaucoup de bits empruntés au module Windows. Je dois faire beaucoup de refactorisation pour qu'il y ait moins de code dupliqué.

Je vais essayer d'avoir un PR avant longtemps.

... alors quel fichier contiendra l'implémentation ? _pswindows.py ou _pslinux.py ? Travaillez-vous dans une succursale accessible au public que je peux consulter ?
Quant à appveyor : je ne pense pas qu'il soit nécessaire de tester cygwin sur toutes les versions de python. Par exemple, Python 2.7 uniquement ou 2.7 + 3.5 conviendrait également. Je ne veux pas introduire de ralentissements car les versions d'appveyor sont déjà assez lentes.

@giampaolo En

Il y a un nouveau _pscygwin.py car il doit prendre des bits de Linux et/ou POSIX et Windows, ainsi que quelques-uns de ses propres bits uniques.

Cool, merci pour la précision.

Pour info... cygwin actuel dit :

$ uname -a
CYGWIN_NT-10.0 Beren 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
$ python3 --version
Python 3.6.1
$ python --version
Python 2.7.13
$ ls /proc
15020/   cygdrive@    meminfo  partitions   self@  sysvipc/
16148/   devices      misc     registry/    stat   uptime
236/     filesystems  mounts@  registry32/  swaps  version
cpuinfo  loadavg      net/     registry64/  sys/
$ ls /proc/$$
cmdline  environ  fd/   mountinfo  ppid   stat    uid
ctty     exe@     gid   mounts     root@  statm   winexename
cwd@     exename  maps  pgid       sid    status  winpid

Est-ce suffisant pour traiter Cygwin comme un port pseudo-standard ?

@binkley Le simple fait d' avoir quelques nœuds dans /proc n'est pas suffisant de loin. S'il vous plaît voir une partie de la discussion dans mes commits dans # 998 pour mieux comprendre les subtilités de cet effort de portage :)

@embray J'ai regardé ça -- c'était déprimant. :) Merci!

Salut. Merci @embray pour votre travail. Cela m'intéresse également beaucoup, je divise mon environnement de travail entre un simple linux et mon poste de travail exécutant également Windows.

Question : J'ai remarqué que vous aviez envoyé des patchs à cygwin, ce qui est super ! Dans quelle mesure votre portage contourne-t-il réellement les limitations de Cygwin, au lieu d'essayer de mieux s'intégrer à Windows lorsque cela est possible ? En regardant brièvement les correctifs, il semble que vous essayez de faire un psutil entièrement compatible avec Windows fonctionnant sur cygwin. Je m'attendrais à ce que le psutil cygwin soit simplement conscient de l'environnement cygwin comme s'il s'agissait d'un port Linux.

Merci encore.

@joaoe Je cygwin séparé pour Python qui fournit un wrapper autour des quelques fonctions externes de la DLL Cygwin (comme pour la conversion de chemin).

En ce qui concerne votre question, je pense que le port essaie d'utiliser autant que possible les interfaces compatibles POSIX dans Cygwin. Mais il ne faut pas dire que Cygwin est un "port Linux". Bien que Cygwin adapte certaines fonctionnalités et inspirations de Linux (comme une partie de la disposition de /proc ), il n'est pas nécessairement garanti d'être jamais 1 à 1 avec des interfaces spécifiques à Linux (il est plus concentré simplement sur la conformité POSIX, mais même là, il y a une poignée d'endroits où des compromis sont nécessaires).

Pour mon portage, certaines parties passent directement par Windows car ces fonctionnalités ne sont pas disponibles dans Cygwin. Cela est particulièrement vrai dans le cas de l'énumération des interfaces réseau. Une alternative serait de simplement désactiver ces fonctionnalités de psutil sur Cygwin, et je ne suis pas totalement opposé à cela non plus. Mais mon expérience jusqu'à présent a été qu'il vaut la peine de conserver ces fonctionnalités jusqu'à ce qu'il soit possible de les porter sur Cygwin (quelque chose que j'aimerais faire, par exemple, est de remplir plus de /proc/net sur Cygwin, mais ce serait un projet beaucoup plus chronophage).

Cela a-t-il juste besoin d'être refactorisé ? Est-il complet en termes de fonctionnalités ?

Je ne suis pas sûr -- je pense qu'il y a eu des fonctionnalités ajoutées à psutil depuis que j'ai commencé sur mon port qui ne sont plus prises en charge. Mais cela pourrait être géré séparément si nécessaire - c'est-à-dire simplement documenter ces fonctionnalités comme non prises en charge sur Cygwin pour le moment, et ajouter une prise en charge si/quand il y a le temps ou une demande suffisante. Je pense notamment aux capteurs.

J'ai également besoin de faire fonctionner la version AppVeyor pour Cygwin. J'ai eu du mal avec quelques tests IIRC.

Il n'y a aucune raison de refuser l'installation. Il n'a pas à fonctionner correctement et peut lever une exception lorsqu'il est utilisé, mais l'installation doit être autorisée. Cela permettrait son utilisation avec Ansible. Mon système local est Windows et je gère des nœuds Linux distants avec Ansible. Ansible copie le module sur le nœud cible pour exécution, ce qui signifie qu'il devrait fonctionner correctement.

@embray c'est toujours d'actualité. Si vous avez le temps, s'il vous plaît, contribuez.

J'ai besoin d'utiliser psutil sur cygwin, j'attends depuis 2014, je me fâche contre toi, la dernière personne avec qui je me suis mis en colère est décédée.

J'adorerais aussi ça.

L'aws cli est horriblement lent sur toutes les plates-formes, y compris cygwin, et malheureusement, aws est à l'origine d'une grande partie d'Internet, y compris mon petit coin de développement.

Il s'avère qu'il existe un petit script python astucieux qui utilisera les bibliothèques python pour accéder aux services aws beaucoup plus rapidement qu'on ne le peut à partir de la ligne de commande, mais (vous l'avez deviné), il nécessite psutil :

https://github.com/janakaud/aws-cli-repl/blob/master/awsr

Pour une intégration continue, GitHub Actions pourrait-il remplacer Appveyor ?