Servo: Keine der Support-Kisten wird aufgeräumt oder lizenzgeprüft

das Plattformverzeichnis hat ein ähnliches Problem

Wenn Sie sich die Liste der ignorierten Dateien ansehen , könnte dies getan werden

Eine Reihe von "unserem" Code (der unter https://github.com/servo/ als Nicht-Forks definiert werden könnte) befindet sich in separaten Repositories und wird durch die Fracht verwendet und ist daher für tidy.py nicht sichtbar. Dies ist also nicht getan, und jetzt härter als zuvor sind wir auf Cargo umgestiegen und alles war ein Untermodul.

Können wir nicht einfach jedes Repository mit einer anderen Konfiguration aufräumen? Diese Repos sollten sich alle im CI-System befinden, damit das gleiche Ziel erreicht wird.

Jedes Repos hat sein eigenes separates CI, das eine Kopie von tidy.py , aber das bedeutet, dass viele Kopien aktualisiert werden müssen, wenn wir etwas hinzufügen möchten.

Aufgeräumt in ein Submodul umziehen? Laden Sie es herunter und führen Sie es während der CI aus? Es gibt einige Ansätze, um dieses Problem zu reduzieren.

Eine Option, die Sie in Betracht ziehen sollten: tidy als servo_tidy tidy auf PyPi hochladen und einfach die neueste Version herunterladen, wann immer wir aufräumen möchten

EDIT: Jack hat mich geschlagen

@frewsxcv Aber Coreys konkretere Version des Vorschlags

In Ordung. Ich habe ein wenig darüber nachgedacht und denke, ich bin bereit für die Herausforderung. Ich werde mich mit meinen Gedanken zurückmelden, bevor ich etwas umsetze; Ich könnte #6999 gleichzeitig damit beheben.

Nach einigem Nachdenken schlage ich Folgendes vor:

1. Virtuelle Umgebungen (bleh?). Beim Ausführen eines beliebigen mach Befehls erstellt/aktiviert Python eine virtuelle Umgebung (die irgendwo wie .pyenv/ oder python/.pyenv/ lebt). Dann werden wir unsere Abhängigkeiten gemäß einer python/requirements.txt Datei installieren/aktualisieren). Auf diese Weise können wir Folgendes aus unserem Baum entfernen und als PyPi-Anforderungen hinzufügen:
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

Dies wird auch #6999 beheben. Abhängig davon, ob die Builder das Arbeitsverzeichnis nach jedem Build wegblasen, müssen wir möglicherweise eine Art Caching-Option oder einen mach-Parameter hinzufügen, um eine Python-Virtualenv anzugeben.

1. Paket tidy.py . Dies könnte bedeuten, dass Sie einfach python/tidy/tidy.py und python/tidy/setup.py erstellen.
2. Integrieren Sie tidy.py in die anderen Repos. Es gibt ein paar Möglichkeiten, dies zu tun:
   
   
   
   1. Geben Sie es auf PyPi frei. Sofern wir kein System zur Automatisierung der Veröffentlichung des Python-Pakets bei jeder Änderung erstellt haben, könnte die Freigabe mühsam sein.
   
   
   2. Wenn Sie alle anderen Repositorys haben, tun Sie einfach:
   
   

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

Lass mich wissen, wenn jemand andere Ideen oder Gedanken hat

Wir haben bereits eine virtualenv für Web-Plattform-Tests, vielleicht könnte sie auch dafür verwendet werden.

Wir haben bereits eine virtualenv für Web-Plattform-Tests, vielleicht könnte sie auch dafür verwendet werden.

Gute Idee. Ich wollte vorschlagen, dass wir auch tests/wpt/harness (wptrunner) aus dem Baum entfernen (und es zu einer Pip-Abhängigkeit machen), aber es sieht so aus, als hätten Sie gerade einige Änderungen an unserer Kopie im Baum vorgenommen :P

Der Upstream dafür ist https://github.com/w3c/wptrunner , und Änderungen, die in unserer Kopie vorgenommen wurden, sollen vorgelagert werden. Ich weiß nicht, warum es kein Submodul ist oder von PyPI installiert wird. Aber das ist irgendwie off-topic, du kannst gerne ein anderes Thema eröffnen.

Ich dachte an tests/wpt/_virtualenv (das erstellt wird, wenn Sie ./mach test-wpt ausführen), nicht an tests/wpt/harness .

Auch wenn dieser _virtualenv mehr Aufgaben erfüllen soll (was in Ordnung ist), sollte er wahrscheinlich höher im Baum aufsteigen.

Ich dachte an tests/wpt/_virtualenv (das erstellt wird, wenn Sie ./mach test-wpt ausführen), nicht an tests/wpt/harness.

Stimmt, hört sich gut an. Der Python-Code zum Generieren/Aktivieren einer neuen virtuellen Umgebung ist nicht sehr viel. Falls wir also in Zukunft jemals WPT-Anforderungen von sauberen Anforderungen trennen möchten (aufgrund von Inkompatibilitäten oder was auch immer), sollte dies nicht so schwierig sein.

Ich bin auch nicht dagegen, den virtualenv-Pfad an einen allgemeineren Ort wie python/_virtualenv

Und wieder hat Jack mich geschlagen

python/_virtualenv scheint ein guter Ort zu sein.

mach verwendet jetzt python/_virtualenv , dank der Auflösung von #6999.

Der Vorteil der Veröffentlichung des Pakets von dort, wo es im Servo-Tree lebt, besteht darin, dass wir nicht alle anderen Repos ändern müssten, wenn wir es schließlich aufteilen; Der Nachteil ist, dass wir einen weiteren Satz von Anmeldeinformationen für pypi verwalten und sicherstellen müssen, dass die erforderlichen Änderungen übertragen werden.

Um auf pypi zu veröffentlichen, müsste jemand eine Kopie von .pypirc , die den Benutzernamen und das Passwort des pypi-Kontos enthält, und dann die Befehle ausführen, um das Paket zu registrieren und hochzuladen. Wenn der "jemand" in diesem Fall der Buildmaster-Host ist, könnten wir den Aktualisierungsprozess des Pakets automatisieren.

Abgesehen davon bin ich mit pypi oder direkter Installation in Ordnung. Pypi ist jetzt mehr Arbeit, die direkte Installation ist zu einem unbestimmten Zeitpunkt in der Zukunft ein größerer Aufwand, und beides erfordert, dass es zu einem Paket aufgeräumt wird.

@shinglyu , willst du aufgeräumt umziehen und es als Python-Paket einrichten, oder soll ich?

@edunham : Das kann ich. :)

Mein Kollege @askeing interessiert sich sehr für dieses Thema, daher überlasse ich dies ihm.

Hallo @edunham ,
Ich versuche es als Python-Paket (mit Tests) hier einzurichten: https://github.com/askeing/servo_tidy

@askeing Danke! Es sieht so aus, als hätten Sie die meiste harte Arbeit bereits erledigt. Mein einziger Nitpick ist, dass es hilfreich wäre, setup() in setup.py die so etwas enthalten wie

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

so dass wir servo-tidy direkt im Skriptabschnitt von .travis.yml eines anderen Projekts aufrufen können, sobald das Paket installiert wurde.

@frewsxcv @larsbergstrom @metajack Was tidy im Servo-Baum im Vergleich zu seinem eigenen Repo lebt? Wie wichtig ist es für das Projekt, den tidy Git-Verlauf aus dem aktuellen Baum zu behalten? Ich persönlich bevorzuge es, wenn immer möglich, die Geschichte aufzubewahren, aber das hat in diesem Fall mehr mit Meinung als mit Notwendigkeit zu tun.

Keine starke Präferenz von mir. Es ist erwähnenswert, dass tidy.py ein Ausgangspunkt für einige neue Mitwirkende zu sein scheint, und dass diese Datei in einem separaten Repository live ist, könnte die Barriere für diese Mitwirkenden erhöhen.

Ich denke, die wichtigste Sorge ist, dass es möglich ist, clean.py zu modifizieren und zu sehen, wie sich diese Änderungen mit möglichst wenigen Zwischenschritten auf ./mach test-tidy auswirken.

Ups, in dieser PR "Fixes" zu sagen, ging ein bisschen zu weit. Die Kisten verwenden es noch nicht in ihrer CI.

Ich bin mir ziemlich sicher, dass dies inzwischen verschwunden ist oder dass andere Probleme dieses abgelöst haben.