Servo: Ninguna de las cajas de soporte está siendo revisada en orden o con licencia

el directorio de la plataforma tiene un problema similar

Mirando la lista de archivos ignorados , esto podría hacerse

Un montón de "nuestro" código (que podría definirse como no bifurcado en https://github.com/servo/) se encuentra en repositorios separados y se usa a través de la carga, por lo que no es visible para tidy.py . Así que esto no está hecho, y ahora es más difícil que antes, cambiamos a Cargo y todo era un submódulo.

¿No podemos poner orden en cada repositorio con una configuración diferente? Todos esos repositorios deberían estar en el sistema de CI, de modo que se lograría el mismo fin.

Cada repos tiene su propio CI separado que podría tener una copia de tidy.py , pero eso significa muchas copias para actualizar cuando queremos agregar algo.

¿Mover ordenado a un submódulo? ¿Descargarlo y ejecutarlo durante CI? Hay algunos enfoques para reducir ese problema.

Una opción a considerar: subir tidy a PyPi como servo_tidy y simplemente descargar la última versión cuando queramos ordenar

EDITAR: Jack me ganó

@frewsxcv Pero me gusta más la versión más concreta de la sugerencia de Corey.

Bien. He pensado un poco en esto y creo que estoy preparado para el desafío. Informaré con mis pensamientos antes de implementar cualquier cosa; Podría arreglar # 6999 simultáneamente con esto.

Después de pensarlo un poco, esto es lo que propongo:

1. Entornos virtuales (¿bleh?). Al ejecutar cualquier comando mach , Python creará / activará un entorno virtual (que vivirá en algún lugar como .pyenv/ o python/.pyenv/ ). Luego instalaremos / actualizaremos nuestras dependencias según un archivo python/requirements.txt ). Esto nos permitirá eliminar lo siguiente de nuestro árbol y agregarlo como requisitos de PyPi:
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

Esto también arreglará # 6999. Dependiendo de si los constructores eliminan el directorio de trabajo después de cada compilación, es posible que necesitemos agregar algún tipo de opción de almacenamiento en caché o un parámetro mach para especificar un virtualenv de Python.

1. Paquete tidy.py . Esto podría significar simplemente crear python/tidy/tidy.py y python/tidy/setup.py .
2. Incorpore tidy.py en los otros repositorios. Hay un par de maneras de hacer esto:
   
   
   
   1. Libérelo en PyPi. A menos que creamos un sistema para automatizar la publicación del paquete de Python cada vez que cambia, lanzarlo podría ser una molestia.
   
   
   2. Tener todos los demás repositorios simplemente hace:
   
   

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

Avísame si alguien tiene otras ideas o pensamientos

Ya tenemos un virtualenv para pruebas de plataforma web, quizás también podría usarse para esto.

Ya tenemos un virtualenv para pruebas de plataforma web, quizás también podría usarse para esto.

Buena idea. Estaba a punto de sugerir que también moviéramos tests/wpt/harness (wptrunner) fuera del árbol (y lo convirtiéramos en una dependencia de pip), pero parece que acaba de hacer algunas ediciones en nuestra copia en el árbol: P

El flujo ascendente para eso es https://github.com/w3c/wptrunner , y se supone que los cambios realizados en nuestra copia deben transmitirse. No sé por qué no es un submódulo o está instalado desde PyPI. Pero eso está un poco fuera de tema, siéntase libre de abrir otro tema.

Estaba pensando en tests/wpt/_virtualenv (que se crea cuando ejecutas ./mach test-wpt ), no tests/wpt/harness .

Además, si ese _virtualenv va a realizar más tareas (lo cual está bien), probablemente debería subir más arriba en el árbol.

Estaba pensando en tests / wpt / _virtualenv (que se crea cuando ejecutas ./mach test-wpt), no tests / wpt / harness.

Bien, suena bien. El código de Python para generar / activar un nuevo entorno virtual no es mucho, por lo que en caso de que alguna vez queramos separar los requisitos de WPT y los requisitos de orden en el futuro (debido a incompatibilidades o lo que sea) no debería ser tan difícil.

Tampoco me opongo a mover la ruta virtualenv a un lugar más genérico como python/_virtualenv

Y una vez más, Jack me ganó

python/_virtualenv parece un buen lugar.

mach ahora usa python/_virtualenv , gracias a la resolución de # 6999.

El beneficio de publicar el paquete desde donde vive en el árbol de servo es que no tendríamos que cambiar todos los demás repositorios si finalmente lo dividimos; el inconveniente es que tenemos que administrar otro conjunto de credenciales para pypi y asegurarnos de que se realicen los cambios necesarios.

Para publicar en pypi, alguien tendría una copia del .pypirc que contiene el nombre de usuario y la contraseña de la cuenta de pypi, luego ejecute los comandos para registrarse y cargar el paquete. Si el "alguien" en este caso es el host buildmaster, podríamos automatizar el proceso de actualización del paquete.

Dicho esto, estoy bien con pypi o con la instalación directa. Pypi es más trabajo ahora, la instalación directa es una molestia mayor en un punto indeterminado en el futuro, y ambos requieren hacer un paquete ordenado.

@shinglyu , ¿quieres moverte ordenado y configurarlo como un paquete de Python, o debo hacerlo yo?

@edunham : Puedo hacer eso. :)

Mi colega @askeing está muy interesado en este tema, así que se lo dejo a él.

Hola @edunham ,
Intento configurarlo como el paquete Python (con pruebas) aquí: https://github.com/askeing/servo_tidy

@askeing ¡ Gracias! Parece que ya has hecho la mayor parte del trabajo duro. Mi único detalle es que sería útil que setup() en setup.py incluyeran algo como

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

para que podamos invocar servo-tidy directamente en la sección de script de .travis.yml de otro proyecto una vez que se haya instalado el paquete.

@frewsxcv @larsbergstrom @metajack ¿Cuáles son sus pensamientos sobre tidy viviendo en el árbol de Servo vs en su propio repositorio? ¿Qué importancia tiene para el proyecto mantener el historial de tidy git del árbol actual? Personalmente, prefiero mantener el historial siempre que sea posible, pero en este caso eso tiene más que ver con la opinión que con la necesidad.

No tengo mucha preferencia. Vale la pena mencionar que tidy.py parece ser un punto de partida para algunos contribuyentes nuevos, y tener ese archivo en un repositorio separado podría aumentar la barrera de esos contribuyentes.

Creo que la preocupación más importante es que es posible modificar tidy.py y ver cómo esos cambios afectan a ./mach test-tidy con la menor cantidad de pasos intermedios posibles.

Vaya, decir "arreglos" en ese PR iba un poco lejos. Las cajas aún no lo están usando en su CI.

Estoy bastante seguro de que esto ya se ha reducido o que otros problemas reemplazaron a este.