Servo: Nenhuma das caixas de suporte está sendo verificada ou verificada a licença

o diretório da plataforma tem um problema semelhante

Olhando para a lista de arquivos ignorados , isso pode ser feito

Vários códigos "nosso" (que podem ser definidos como não-bifurcados em https://github.com/servo/) estão em repositórios separados e são usados ​​por meio de carga e, portanto, não são visíveis para tidy.py . Então isso não é feito, e agora mais difícil do que antes mudamos para Cargo e tudo era um submódulo.

Não podemos simplesmente colocar o tidy em cada repositório com uma configuração diferente? Esses repos devem estar todos no sistema de CI, para que tenha o mesmo fim.

Cada repositório tem seu próprio CI separado que pode ter uma cópia de tidy.py , mas isso significa muitas cópias para atualizar quando quisermos adicionar algo.

Mover arrumado para um submódulo? Faça o download e execute-o durante o CI? Existem algumas abordagens para reduzir esse problema.

Uma opção a considerar: enviar tidy para PyPi como servo_tidy e apenas baixar a versão mais recente sempre que quisermos limpar

EDIT: jack chegou antes de mim

@frewsxcv Mas eu gosto mais da versão mais concreta da sugestão de Corey.

Tudo bem. Eu pensei um pouco sobre isso e acho que estou pronto para o desafio. Vou relatar meus pensamentos antes de implementar qualquer coisa; Eu posso consertar # 6999 simultaneamente com isso.

Depois de pensar um pouco, aqui está o que proponho:

1. Ambientes virtuais (bleh?). Ao executar qualquer comando mach , o Python criará / ativará um ambiente virtual (que residirá em algum lugar como .pyenv/ ou python/.pyenv/ ). Em seguida, instalaremos / atualizaremos nossas dependências de acordo com um arquivo python/requirements.txt ). Isso nos permitirá remover o seguinte de nossa árvore e adicioná-los como requisitos PyPi:
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

Isso também corrigirá # 6999. Dependendo se os construtores eliminam o diretório de trabalho após cada construção, podemos precisar adicionar algum tipo de opção de cache ou um parâmetro mach para especificar um virtualenv Python.

1. Pacote tidy.py . Isso pode significar apenas criar python/tidy/tidy.py e python/tidy/setup.py .
2. Incorpore tidy.py aos outros repos. Existem algumas maneiras de fazer isso:
   
   
   
   1. Solte-o no PyPi. A menos que tenhamos criado um sistema para automatizar a publicação do pacote Python sempre que ele muda, liberá-lo pode ser uma dor.
   
   
   2. Tendo todos os outros repositórios apenas para fazer:
   
   

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

Avise-me se alguém tiver outras ideias ou pensamentos

Já temos um virtualenv para testes de plataforma web, talvez também possa ser usado para isso.

Já temos um virtualenv para testes de plataforma web, talvez também possa ser usado para isso.

Boa ideia. Eu estava prestes a sugerir que também movêssemos tests/wpt/harness (wptrunner) para fora da árvore (e o tornássemos uma dependência de pip), mas parece que você acabou de fazer algumas edições em nossa cópia na árvore: P

O upstream para isso é https://github.com/w3c/wptrunner , e as alterações feitas em nossa cópia devem ser upstream. Não sei porque não é um submódulo ou instalado a partir do PyPI. Mas isso está meio fora do assunto, fique à vontade para abrir outra edição.

Eu estava pensando em tests/wpt/_virtualenv (que é criado quando você executa ./mach test-wpt ), não tests/wpt/harness .

Além disso, se esse _virtualenv vai realizar mais tarefas (o que está bem), ele provavelmente deve subir mais alto na árvore.

Eu estava pensando em tests / wpt / _virtualenv (que é criado quando você executa ./mach test-wpt), não tests / wpt / harness.

Certo, parece bom. O código Python para gerar / ativar um novo ambiente virtual não é muito, portanto, caso desejemos separar os requisitos do WPT e os requisitos organizados no futuro (devido a incompatibilidades ou o que quer que seja), não deve ser tão difícil.

Também não me oponho a mover o caminho virtualenv para um lugar mais genérico como python/_virtualenv

E mais uma vez, jack chegou antes de mim

python/_virtualenv parece um bom lugar.

mach agora usa python/_virtualenv , graças à resolução de # 6999.

O benefício de publicar o pacote de onde ele está na árvore servo é que não teríamos que mudar todos os outros repositórios se eventualmente o dividíssemos; a desvantagem é que temos que gerenciar outro conjunto de credenciais para pypi e garantir que as alterações necessárias sejam enviadas.

Para publicar no pypi, alguém teria uma cópia do .pypirc que contém o nome de usuário e a senha da conta pypi e, em seguida, executaria os comandos para registrar e fazer upload do pacote. Se o "alguém" neste caso for o host buildmaster, poderíamos automatizar o processo de atualização do pacote.

Com isso dito, estou bem com a instalação pypi ou direta. Pypi é mais trabalhoso agora, a instalação direta é um incômodo maior em um ponto indeterminado no futuro, e ambos exigem que seja organizado em um pacote.

@shinglyu , você quer mudar de lugar e configurá-lo como um pacote Python, ou devo?

@edunham : Eu posso fazer isso. :)

Meu colega @askeing está muito interessado neste assunto, então vou deixar isso para ele.

Olá @edunham ,
Tento configurá-lo como o pacote Python (com testes) aqui: https://github.com/askeing/servo_tidy

@askeing Obrigado! Parece que você já fez a maior parte do trabalho árduo. Meu único detalhe é que seria útil ter setup() em setup.py incluindo algo como

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

para que possamos invocar servo-tidy diretamente na seção de script de .travis.yml de outro projeto, uma vez que o pacote tenha sido instalado.

@frewsxcv @larsbergstrom @metajack O que você acha de tidy viver na árvore Servo versus em seu próprio repo? Quão importante para o projeto é manter o histórico tidy git da árvore atual? Eu pessoalmente prefiro manter a história sempre que possível, mas isso tem mais a ver com opinião do que com necessidade neste caso.

Nenhuma preferência forte de minha parte. Vale a pena mencionar que tidy.py parece ser um ponto de partida para alguns novos contribuidores, e ter esse arquivo em um repositório separado pode aumentar a barreira desses contribuidores.

Acho que a preocupação mais importante é que é possível modificar tidy.py e ver como essas mudanças afetam ./mach test-tidy com o menor número possível de etapas intermediárias.

Opa, dizer "consertos" naquele PR estava indo um pouco longe. As caixas ainda não o estão usando em seu CI.

Tenho certeza de que isso já foi desativado ou de que outros problemas substituíram este.