Servo: Aucune des caisses de support n'est en cours de vérification de l'ordre ou de la licence

le répertoire de la plate-forme a un problème similaire

En regardant la liste des fichiers ignorés , cela peut être fait

Un tas de "notre" code (qui pourrait être défini comme non-forks sous https://github.com/servo/) est dans des référentiels séparés et utilisé par le biais du fret, et n'est donc pas visible pour tidy.py . Donc ce n'est pas fait, et maintenant plus difficile qu'avant, nous sommes passés à Cargo et tout était un sous-module.

Ne pouvons-nous pas simplement mettre de l'ordre dans chaque dépôt avec une configuration différente ? Ces pensions devraient toutes être dans le système CI, ce qui permettrait d'atteindre le même objectif.

Chaque dépôt a son propre CI séparé qui peut avoir une copie de tidy.py , mais cela signifie de nombreuses copies à mettre à jour lorsque nous voulons ajouter quelque chose.

Déplacer bien rangé vers un sous-module ? Le télécharger et l'exécuter pendant CI ? Il existe quelques approches pour réduire ce problème.

Une option à considérer : télécharger tidy sur PyPi en tant que servo_tidy et télécharger simplement la dernière version chaque fois que nous voulons ranger

EDIT : Jack m'a devancé

@frewsxcv Mais j'aime mieux la version plus concrète de la suggestion de Corey.

Bien. J'y ai pensé un peu et je pense que je suis prêt à relever le défi. Je rendrai compte de mes réflexions avant de mettre en œuvre quoi que ce soit ; Je pourrais peut-être corriger le #6999 en même temps.

Après réflexion, voici ce que je vous propose :

1. Environnements virtuels (bleu ?). Lors de l'exécution d'une commande mach , Python créera/activera un environnement virtuel (qui vivra quelque part comme .pyenv/ ou python/.pyenv/ ). Ensuite, nous allons installer/mettre à jour nos dépendances selon un fichier python/requirements.txt ). Cela nous permettra de supprimer les éléments suivants de notre arbre et de les ajouter en tant qu'exigences PyPi :
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

Cela corrigera également #6999. Selon que les constructeurs suppriment ou non le répertoire de travail après chaque construction, nous devrons peut-être ajouter une sorte d'option de mise en cache ou un paramètre mach pour spécifier un virtualenv Python.

1. Forfait tidy.py . Cela pourrait signifier simplement créer python/tidy/tidy.py et python/tidy/setup.py .
2. Incorporez tidy.py dans les autres dépôts. Il existe plusieurs manières de procéder :
   
   
   
   1. Relâchez-le sur PyPi. À moins que nous ne créions un système pour automatiser la publication du package Python chaque fois qu'il change, sa publication pourrait être pénible.
   
   
   2. Faire en sorte que tous les autres référentiels fassent simplement :
   
   

pip install -e git+https://github.com/servo/servo.git#egg=servo_tidy&subdirectory=python/tidy

Faites-moi savoir si quelqu'un a d'autres idées ou pensées

Nous avons déjà un virtualenv pour les tests de plates-formes Web, il pourrait peut-être également être utilisé pour cela.

Nous avons déjà un virtualenv pour les tests de plates-formes Web, il pourrait peut-être également être utilisé pour cela.

Bonne idée. J'étais sur le point de suggérer de déplacer également tests/wpt/harness (wptrunner) hors de l'arborescence (et d'en faire une dépendance pip), mais il semble que vous veniez d'apporter quelques modifications à notre copie dans l'arborescence :P

L'amont pour cela est https://github.com/w3c/wptrunner , et les modifications apportées dans notre copie sont censées être en amont. Je ne sais pas pourquoi ce n'est pas un sous-module ou installé à partir de PyPI. Mais c'est un peu hors sujet, n'hésitez pas à ouvrir un autre sujet.

Je pensais à tests/wpt/_virtualenv (qui est créé lorsque vous exécutez ./mach test-wpt ), pas à tests/wpt/harness .

De plus, si ce _virtualenv va faire plus de tâches (ce qui est bien), il devrait probablement monter plus haut dans l'arborescence.

Je pensais à tests/wpt/_virtualenv (qui est créé lorsque vous exécutez ./mach test-wpt), et non à tests/wpt/harness.

D'accord, ça sonne bien. Le code Python pour générer/activer un nouvel environnement virtuel n'est pas très important, donc au cas où nous voudrions séparer les exigences WPT et les exigences ordonnées à l'avenir (en raison d'incompatibilités ou autre), cela ne devrait pas être si difficile.

Je ne suis pas non plus opposé à déplacer le chemin virtualenv vers un endroit plus générique comme python/_virtualenv

Et encore une fois, Jack m'a devancé

python/_virtualenv semble être un bon endroit.

mach utilise maintenant python/_virtualenv , grâce à la résolution de #6999.

L'avantage de publier le paquet depuis l'endroit où il se trouve dans l'arborescence servo est que nous n'aurions pas à changer tous les autres dépôts si nous le découpions finalement ; l'inconvénient est que nous devons gérer un autre ensemble d'informations d'identification pour pypi et nous assurer que les modifications requises sont appliquées.

Pour publier sur pypi, quelqu'un aurait une copie du .pypirc qui contient le nom d'utilisateur et le mot de passe du compte pypi, puis exécuterait les commandes pour enregistrer et télécharger le package. Si le "quelqu'un" dans ce cas est l'hôte buildmaster, nous pourrions automatiser le processus de mise à jour du package.

Cela dit, je suis d'accord avec pypi ou l'installation directe. Pypi est plus de travail maintenant, l'installation directe est un plus gros problème à un moment indéterminé dans le futur, et les deux nécessitent de faire de l'ordre dans un package.

@shinglyu , voulez-vous déplacer le rangement et le configurer en tant que package Python, ou dois-je le faire ?

@edunham : Je peux le faire. :)

Mon collègue @askeing est très intéressé par cette question, je vais donc lui laisser cela.

Salut @edunham ,
J'essaie de le configurer en tant que package Python (avec tests) ici : https://github.com/askeing/servo_tidy

@demande Merci ! Il semble que vous ayez déjà fait le plus gros du travail. Mon seul pinaille est qu'il serait utile d'avoir setup() dans setup.py inclure quelque chose comme

entry_points={
        'console_scripts': [
            'servo-tidy=servo_tidy:scan',
        ],
    },

afin que nous puissions simplement invoquer servo-tidy directement dans la section script du .travis.yml d'un autre projet une fois le package installé.

@frewsxcv @larsbergstrom @metajack Que tidy vivant dans l'arbre Servo vs dans son propre repo ? Dans quelle mesure est-il important pour le projet de conserver l'historique tidy git de l'arborescence actuelle ? Personnellement, je préfère garder l'histoire chaque fois que possible, mais cela a plus à voir avec l'opinion que la nécessité dans ce cas.

Aucune préférence marquée de ma part. Il convient de mentionner que tidy.py semble être un point de départ pour certains nouveaux contributeurs, et que le fait que ce fichier vive dans un référentiel séparé pourrait augmenter la barrière de ces contributeurs.

Je pense que la préoccupation la plus importante est qu'il est possible de modifier tidy.py et de voir comment ces changements affectent ./mach test-tidy avec le moins d'étapes intermédiaires possibles.

Oups, dire "correctifs" dans ce PR allait un peu loin. Les caisses ne l'utilisent pas encore dans leur CI.

Je suis à peu près sûr que cela a déjà baissé, ou que d'autres problèmes ont remplacé celui-ci.