1
フォークされたプロジェクトのsetup.pyの承認されたベストプラクティス
環境: 私は何かをするツールがあるかどうかを探していました(私の場合、PythonテストフレームワークからのHTTPログインスペクションを可能にするプロキシを探していました)。 わずかな調整のみを必要とするツールが判明し、過去5か月(pymiproxy)に更新がないため、かなり安定していて成熟しているように見えたので、プロジェクトをフォークして(ここまで)、それを機能させました必要に応じて。元のプロジェクトの背後にある目標は単純さであり、特に関係するファイルの1つが現在の雇用主にとってのみ有用であるため、プルリクエストが受け入れられるとは思えません。 最後に、setup.pyファイルを更新する必要があると思いましたが、よくわかりません-私はフォークに対して「有用な」量の作業を行いました。元のファイルをそのままにして、自分のモジュールでサブクラス化している間、重要な追加機能。 Pythonによってインストールされるため、このモジュールの「作成者」であると主張するのが快適だとは思わないが、forkプロジェクトの作成者として、元のプロジェクトの作成者に宛てたサポートメールを残しておくことに抵抗がある。 質問: フォークされたプロジェクトの一般的に受け入れられているベストプラクティスは何ですか?プロジェクトの名前を変更して、目的が異なることを示す必要がありますか?元のプロジェクトはpip経由では利用できません。そうでない場合、私のプロジェクトの構造により、フォークの代わりに元のプロジェクトを依存関係としてラップするだけで済みます。実際に変更をロールバックし、これらを新しいプロジェクトに入れて、両方をpyplにリストする必要がありますか、それとも元の作者に代わってこれを行っているのですか? ノート: 速読を支援するために見出しが追加されました。私は受け入れられたベストプラクティスを探しているので、信頼できるブログの投稿であれ、同じことを行った他のプロジェクトの例であれ、それらをバックアップするための情報源がない意見はありません。