Servo: Ни один из ящиков поддержки не проверяется аккуратно или лицензируется

в каталоге платформы есть аналогичная проблема

Глядя на список игнорируемых файлов , это можно сделать

Куча «нашего» кода (который может быть определен как не-форк на https://github.com/servo/) находится в отдельных репозиториях и используется через Cargo, поэтому не виден для tidy.py . Так что это еще не сделано, и теперь сложнее, чем раньше, мы перешли на Cargo, и все было подмодулем.

Разве мы не можем просто добавить аккуратность в каждое репо с другой конфигурацией? Все эти репозитории должны быть в системе CI, чтобы достичь той же цели.

У каждого репозитория есть свой собственный отдельный CI, который может иметь копию tidy.py , но это означает, что нужно обновлять множество копий, когда мы хотим что-то добавить.

Переместить приборку в подмодуль? Скачать и запустить во время CI? Есть несколько подходов к решению этой проблемы.

Вариант для рассмотрения: загрузка tidy в PyPi как servo_tidy и загрузка последней версии всякий раз, когда мы хотим привести в порядок

РЕДАКТИРОВАТЬ: Джек победил меня

@frewsxcv Но мне больше всего нравится более конкретная версия предложения Кори.

Хорошо. Я подумал об этом немного и думаю, что готов принять вызов. Я отчитаюсь со своими мыслями, прежде чем что-либо реализовывать; Возможно, я смогу исправить # 6999 одновременно с этим.

Поразмыслив, я предлагаю следующее:

1. Виртуальные среды (бле?). После выполнения любой команды mach Python создаст / активирует виртуальную среду (которая будет находиться где-то вроде .pyenv/ или python/.pyenv/ ). Затем мы установим / обновим наши зависимости в соответствии с файлом python/requirements.txt ). Это позволит нам удалить следующее из нашего дерева и добавить их в качестве требований PyPi:
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

Это также исправит # 6999. В зависимости от того, удаляют ли разработчики рабочий каталог после каждой сборки, нам может потребоваться добавить какую-то опцию кэширования или параметр mach для указания виртуального Python Python.

1. Пакет tidy.py . Это может означать просто создание python/tidy/tidy.py и python/tidy/setup.py .
2. Включите tidy.py в другие репозитории. Сделать это можно двумя способами:
   
   
   
   1. Выпустите его на PyPi. Если мы не создадим систему для автоматизации публикации пакета Python всякий раз, когда он изменяется, его выпуск может быть проблемой.
   
   
   2. Все остальные репозитории просто делают:
   
   

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

Сообщите мне, есть ли у кого-нибудь другие идеи или мысли

У нас уже есть virtualenv для тестирования веб-платформы, возможно, его тоже можно было бы использовать для этого.

У нас уже есть virtualenv для тестирования веб-платформы, возможно, его тоже можно было бы использовать для этого.

Отличная идея. Я собирался предложить нам также переместить tests/wpt/harness (wptrunner) из дерева (и сделать его зависимостью от пункта), но похоже, что вы только что внесли некоторые изменения в нашу копию в дереве: P

Восходящим потоком для этого является https://github.com/w3c/wptrunner , и предполагается, что изменения, внесенные в нашу копию, будут переданы вверх. Я не знаю, почему это не подмодуль и не установлен из PyPI. Но это не по теме, не стесняйтесь открывать другой выпуск.

Я думал о tests/wpt/_virtualenv (который создается при запуске ./mach test-wpt ), а не о tests/wpt/harness .

Также, если этот _virtualenv будет выполнять больше обязанностей (что нормально), он, вероятно, должен подняться выше по дереву.

Я думал о tests / wpt / _virtualenv (который создается при запуске ./mach test-wpt), а не о tests / wpt / harness.

Хорошо, звучит хорошо. Код Python для создания / активации новой виртуальной среды не очень большой, поэтому, если мы когда-либо захотим разделить требования WPT и требования к аккуратности в будущем (из-за несовместимости или чего-то еще), это не должно быть так сложно.

Я также не против переноса пути virtualenv в более общее место, например python/_virtualenv

И снова Джек победил меня.

python/_virtualenv кажется хорошим местом.

mach теперь использует python/_virtualenv , благодаря разрешению # 6999.

Преимущество публикации пакета из того места, где он находится в дереве сервоприводов, состоит в том, что нам не придется изменять все другие репозитории, если мы в конечном итоге разделим его; недостатком является то, что мы должны управлять еще одним набором учетных данных для pypi и обеспечивать внесение необходимых изменений.

Чтобы опубликовать на pypi, у кого-то должна быть копия .pypirc , содержащая имя пользователя и пароль учетной записи pypi, а затем запускать команды для регистрации и загрузки пакета. Если «кто-то» в данном случае является хостом buildmaster, мы могли бы автоматизировать процесс обновления пакета.

С учетом сказанного, меня устраивает как pypi, так и прямая установка. Pypi - это больше работы сейчас, прямая установка - большая проблема в неопределенный момент в будущем, и оба требуют внесения аккуратности в пакет.

@shinglyu , вы хотите переместить приборку и настроить ее как пакет Python, или я должен?

@edunham : Я могу это сделать. :)

Мой коллега @askeing очень заинтересовался этим вопросом, поэтому я оставлю это ему.

Привет @edunham ,
Я пытаюсь настроить его как пакет Python (с тестами) здесь: https://github.com/askeing/servo_tidy

@askeing Спасибо! Похоже, вы уже проделали большую часть тяжелой работы. Моя единственная придирка заключается в том, что было бы полезно, чтобы setup() в setup.py включал что-то вроде

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

так что мы можем просто вызвать servo-tidy непосредственно в разделе сценария .travis.yml другого проекта после установки пакета.

@frewsxcv @larsbergstrom @metajack Что вы думаете о tidy живущем в дереве серво и в собственном репо? Насколько важно для проекта сохранить историю tidy git из текущего дерева? Я лично предпочитаю вести историю, когда это возможно, но в данном случае это больше связано с мнением, чем с необходимостью.

С моей стороны нет особых предпочтений. Стоит упомянуть, что tidy.py кажется отправной точкой для некоторых новых участников, и размещение этого файла в отдельном репозитории может увеличить барьер для этих участников.

Я думаю, что самая важная проблема заключается в том, что можно изменить tidy.py и посмотреть, как эти изменения повлияют на ./mach test-tidy с наименьшим количеством возможных промежуточных шагов.

Упс, сказать «исправления» в этом пиаре - это слишком далеко. Ящики фактически еще не используют его в своем CI.

Я почти уверен, что это уже не работает, или что другие проблемы вытеснили эту.