Servo: どのサポートクレートもきちんとチェックまたはライセンスチェックされていません

プラットフォームディレクトリにも同様の問題があります

無視されたファイルの

一連の「私たちの」コード（https://github.com/servo/で非フォークとして定義されている可能性があります）は別々のリポジトリにあり、貨物を通じて使用されるため、 tidy.pyは表示されません。 したがって、これは行われず、Cargoに切り替える前よりも難しくなり、すべてがサブモジュールでした。

異なる設定で各リポジトリに整理することはできませんか？ これらのリポジトリはすべてCIシステム内にある必要があります。そうすれば、同じ目的を達成できます。

各リポジトリには、 tidy.pyコピーを持つことができる独自の個別のCIがありますが、これは、何かを追加するときに更新するコピーが多数あることを意味します。

整頓してサブモジュールに移動しますか？ ダウンロードしてCI中に実行しますか？ その問題を減らすためのいくつかのアプローチがあります。

考慮すべきオプション： tidyをservo_tidyとしてPyPiにアップロードし、整理したいときはいつでも最新バージョンをダウンロードする

編集：ジャックはそれに私を打ち負かした

@frewsxcvしかし、私はCoreyのより具体的な提案のバージョンが一番好きです。

大丈夫。 私はこれについて少し考えて、挑戦する準備ができていると思います。 何かを実装する前に、自分の考えを報告します。 これと同時に＃6999を修正できるかもしれません。

少し考えた後、これが私が提案するものです：

1. 仮想環境（ブレ？）。 machコマンドを実行すると、Pythonは仮想環境（ .pyenv/やpython/.pyenv/ような場所に存在します）を作成/アクティブ化します。 次に、 python/requirements.txtファイルに従って依存関係をインストール/更新します）。 これにより、ツリーから以下を削除し、PyPi要件として追加できるようになります。
   
   
   
   • python/mozdebug
   
   
   • python/mozinfo
   
   
   • python/mozlog
   
   
   • dependencies/*
   
   
   • python/toml
   
   

これにより、＃6999も修正されます。 ビルダーがビルドのたびに作業ディレクトリを吹き飛ばすかどうかによっては、Pythonvirtualenvを指定するための何らかのキャッシュオプションまたはmachパラメーターを追加する必要がある場合があります。

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

他に何かアイデアや考えがあれば教えてください

Webプラットフォームテスト用のvirtualenvがすでにありますが、これにも使用できる可能性があります。

Webプラットフォームテスト用のvirtualenvがすでにありますが、これにも使用できる可能性があります。

良いアイデア。 tests/wpt/harness （wptrunner）もツリーから移動する（そしてそれをpip依存関係にする）ことを提案しようとしていましたが、ツリー内のコピーにいくつかの編集を加えたようです：P

そのためのアップストリームはhttps://github.com/w3c/wptrunnerであり、コピーに加えられた変更はアップストリームであると想定されています。 なぜそれがサブモジュールではないのか、PyPIからインストールされていないのかわかりません。 しかし、それはちょっとオフトピックです。別の問題を自由に開いてください。

tests/wpt/harnessではなく、 tests/wpt/_virtualenv （ ./mach test-wptを実行すると作成される）を考えていました。

また、その_virtualenvがより多くの役割を実行する場合（これは問題ありません）、おそらくツリーの上位に移動する必要があります。

私はtests / wpt / harnessではなくtests / wpt / _virtualenv（./ mach test-wptを実行すると作成される）を考えていました。

そうですね、いいですね。 新しい仮想環境を生成/アクティブ化するPythonコードはそれほど重要ではないため、将来WPT要件と整頓された要件を分離したい場合（非互換性などのため）、それほど難しくはありません。

また、virtualenvパスをpython/_virtualenvようなより一般的な場所に移動することに反対していません。

そしてまたしても、ジャックは私をそれに打ち負かしました

python/_virtualenvは良い場所のようです。

＃6999の解像度のおかげで、マッハはpython/_virtualenv使用するようになりました。

パッケージをサーボツリー内のどこから公開することの利点は、最終的に分割した場合でも、他のすべてのリポジトリを変更する必要がないことです。 欠点は、pypiのさらに別のクレデンシャルのセットを管理し、必要な変更がプッシュされることを確認する必要があることです。

pypiで公開するには、誰かがpypiアカウントのユーザー名とパスワードを保持する.pypircコピーを持っており、コマンドを実行してパッケージを登録およびアップロードします。 この場合の「誰か」がbuildmasterホストである場合、パッケージの更新プロセスを自動化できます。

そうは言っても、私はpypiまたは直接インストールのどちらでも問題ありません。 Pypiは現在より多くの作業を行っており、直接インストールは将来の不確定な時点でより大きな手間がかかり、どちらもパッケージに整頓する必要があります。

@shinglyu 、きちんと移動してPythonパッケージとして設定しますか、それとも私がしますか？

@edunham ：それはできます。 :)

同僚の@askeingはこの問題に非常に興味を持っているので、これは彼に任せます。

こんにちは@edunham 、
ここでPythonパッケージ（テスト付き）としてセットアップしようとしています： https ：

@askeingありがとうございます！ 大変な作業のほとんどはすでに完了しているようです。 私の唯一の落とし穴は、 setup.py setup()に次のようなものを含めると便利だということです。

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

これにより、パッケージがインストールされたら、別のプロジェクトの.travis.ymlのスクリプトセクションでservo-tidy直接呼び出すことができます。

@frewsxcv @larsbergstrom @metajackサーボツリーに住んでいるtidy独自のリポジトリに住んでいるtidy git履歴を保持することは、プロジェクトにとってどれほど重要ですか？ 私は個人的には可能な限り歴史を残すことを好みますが、それはこの場合の必要性よりも意見と関係があります。

私からの強い好みはありません。 tidy.pyは一部の新しい寄稿者の出発点のようであり、そのファイルを別のリポジトリに保存すると、寄稿者の障壁が増える可能性があることは言及する価値があります。

最も重要な懸念は、tidy.pyを変更して、それらの変更が./mach test-tidyどのように影響するかを可能な限り少ない中間ステップで確認できることだと思います。

おっと、そのPRの「修正」は少し遠いところだったと言っています。 木枠はまだ実際にはCIで使用していません。

これはもうダウンしているか、他の問題がこれに取って代わったと確信しています。