Servo: Tak satu pun dari peti dukungan sedang diperiksa rapi atau diperiksa lisensinya

direktori platform memiliki masalah yang sama

Melihat daftar file yang diabaikan , ini mungkin dilakukan

Sekelompok kode "kami" (yang mungkin didefinisikan sebagai non-garpu di bawah https://github.com/servo/) berada di repositori terpisah dan digunakan melalui kargo, sehingga tidak terlihat oleh tidy.py . Jadi ini tidak dilakukan, dan sekarang lebih sulit dari sebelumnya kami beralih ke Cargo dan semuanya adalah submodule.

Tidak bisakah kita merapikan setiap repo dengan konfigurasi yang berbeda? Semua repo itu harus ada dalam sistem CI, sehingga akan mencapai tujuan yang sama.

Setiap repo memiliki CI terpisah yang dapat memiliki salinan tidy.py , tetapi itu berarti banyak salinan yang harus diperbarui ketika kita ingin menambahkan sesuatu.

Pindahkan rapi ke submodul? Unduh dan jalankan selama CI? Ada beberapa pendekatan untuk mengurangi masalah itu.

Opsi untuk dipertimbangkan: mengunggah tidy ke PyPi sebagai servo_tidy dan cukup unduh versi terbaru kapan pun kita ingin merapikan

EDIT: jack mengalahkan saya untuk itu

@frewsxcv Tapi saya paling suka versi Corey yang lebih konkret dari saran.

Baik. Saya telah memikirkan hal ini sebentar dan berpikir saya siap menghadapi tantangan. Saya akan melaporkan kembali dengan pemikiran saya sebelum menerapkan apa pun; Saya mungkin dapat memperbaiki #6999 secara bersamaan dengan ini.

Setelah beberapa pemikiran, inilah yang saya usulkan:

1. Lingkungan virtual (bleh?). Saat menjalankan perintah mach , Python akan membuat/mengaktifkan lingkungan virtual (yang akan hidup di suatu tempat seperti .pyenv/ atau python/.pyenv/ ). Kemudian kami akan menginstal/memperbarui dependensi kami sesuai dengan file python/requirements.txt ). Ini akan memungkinkan kami untuk menghapus yang berikut dari pohon kami dan menambahkannya sebagai persyaratan PyPi:
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

Ini juga akan memperbaiki #6999. Bergantung pada apakah builder menerbangkan direktori kerja setelah setiap build, kita mungkin perlu menambahkan semacam opsi caching atau parameter mach untuk menentukan virtualenv Python.

1. Paket tidy.py . Ini bisa berarti hanya membuat python/tidy/tidy.py dan python/tidy/setup.py .
2. Masukkan tidy.py ke dalam repo lainnya. Ada beberapa cara untuk melakukan ini:
   
   
   
   1. Lepaskan di PyPi. Kecuali jika kami membuat sistem untuk mengotomatiskan penerbitan paket Python setiap kali berubah, melepaskannya bisa merepotkan.
   
   
   2. Memiliki semua repositori lain lakukan saja:
   
   

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

Beri tahu saya jika ada yang punya ide atau pemikiran lain

Kami sudah memiliki virtualenv untuk web-platform-tests, mungkin bisa juga digunakan untuk ini.

Kami sudah memiliki virtualenv untuk web-platform-tests, mungkin bisa juga digunakan untuk ini.

Ide bagus. Saya akan menyarankan agar kami juga memindahkan tests/wpt/harness (wptrunner) dari pohon (dan menjadikannya ketergantungan pip), tetapi sepertinya Anda baru saja mengedit salinan di pohon kami: P

Hulu untuk itu adalah https://github.com/w3c/wptrunner , dan perubahan yang dibuat pada salinan kami seharusnya di-upstream. Saya tidak tahu mengapa itu bukan submodul atau diinstal dari PyPI. Tapi itu agak keluar dari topik, jangan ragu untuk membuka masalah lain.

Saya sedang memikirkan tests/wpt/_virtualenv (yang dibuat ketika Anda menjalankan ./mach test-wpt ), bukan tests/wpt/harness .

Juga jika _virtualenv itu akan melakukan lebih banyak tugas (yang baik-baik saja), itu mungkin harus bergerak lebih tinggi ke atas pohon.

Saya sedang memikirkan tes/wpt/_virtualenv (yang dibuat ketika Anda menjalankan ./mach test-wpt), bukan tes/wpt/harness.

Benar, kedengarannya bagus. Kode Python untuk menghasilkan/mengaktifkan lingkungan virtual baru tidak terlalu banyak, jadi jika kita ingin memisahkan persyaratan WPT dan persyaratan rapi di masa mendatang (karena ketidakcocokan atau apa pun) seharusnya tidak terlalu sulit.

Saya juga tidak menentang memindahkan jalur virtualenv ke tempat yang lebih umum seperti python/_virtualenv

Dan sekali lagi, jack mengalahkan saya untuk itu

python/_virtualenv sepertinya tempat yang bagus.

mach sekarang menggunakan python/_virtualenv , berkat resolusi #6999.

Manfaat memublikasikan paket dari tempatnya berada di pohon servo adalah kita tidak perlu mengubah semua repo lain jika akhirnya kita membaginya; kekurangannya adalah kita harus mengelola set kredensial lain untuk pypi dan memastikan perubahan yang diperlukan didorong.

Untuk memublikasikan di pypi, seseorang akan memiliki salinan .pypirc yang menyimpan nama pengguna dan kata sandi akun pypi, kemudian menjalankan perintah untuk mendaftar dan mengunggah paket. Jika "seseorang" dalam hal ini adalah host buildmaster, kami dapat mengotomatiskan proses pembaruan paket.

Dengan itu, saya baik-baik saja dengan pypi atau instalasi langsung. Pypi lebih banyak pekerjaan sekarang, instalasi langsung adalah kerumitan yang lebih besar pada titik yang tidak ditentukan di masa depan, dan keduanya perlu dirapikan menjadi sebuah paket.

@shinglyu , apakah Anda ingin bergerak rapi dan mengaturnya sebagai paket Python, atau haruskah saya?

@edunham : Saya bisa melakukan itu. :)

Rekan saya @askeing sangat tertarik dengan masalah ini, jadi saya akan menyerahkan ini padanya.

Hai @edunham ,
Saya mencoba mengaturnya sebagai paket Python (dengan tes) di sini: https://github.com/askeing/servo_tidy

@askeing Terima kasih! Sepertinya Anda sudah melakukan sebagian besar kerja keras. Satu-satunya nitpick saya adalah akan sangat membantu jika setup() di setup.py menyertakan sesuatu seperti

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

sehingga kita dapat memanggil servo-tidy langsung di bagian skrip .travis.yml proyek lain setelah paket diinstal.

@frewsxcv @larsbergstrom @metajack Apa pendapat Anda tentang tidy tinggal di pohon Servo vs di reponya sendiri? Seberapa penting bagi proyek untuk menjaga riwayat git tidy dari pohon saat ini? Saya pribadi lebih suka menyimpan sejarah bila memungkinkan, tetapi itu lebih berkaitan dengan pendapat daripada kebutuhan dalam kasus ini.

Tidak ada preferensi yang kuat dari saya. Patut disebutkan bahwa tidy.py tampaknya menjadi titik awal untuk beberapa kontributor baru, dan menyimpan file itu di repositori terpisah dapat meningkatkan penghalang para kontributor tersebut.

Saya pikir perhatian yang paling penting adalah memungkinkan untuk memodifikasi rapi.py dan melihat bagaimana perubahan itu mempengaruhi ./mach test-tidy dengan langkah-langkah perantara sesedikit mungkin.

Ups, mengatakan "perbaikan" dalam PR itu agak berlebihan. Peti belum benar-benar menggunakannya di CI mereka.

Saya cukup yakin ini sudah turun sekarang, atau masalah lain menggantikan yang ini.