5

プロジェクトは、単一のパッケージまたは複数のパッケージとして編成できる場合があります。そのような状況にあるとき、どの選択肢がより良いかをどのように判断すべきでしょうか?

4

1 に答える 1

10

プロジェクトを複数のパッケージに配布することには、差し迫った欠点がいくつかあります。

  • ビルドプロセスはより複雑ですcabal build
  • リリースとバージョン番号を調整する必要があります
  • ユーザーは複数のパッケージをインストールして依存する必要があります
  • API ドキュメントはハッキングで散らばっています

しかし、パッケージのサブセットのみに依存するユーザーにとっては、潜在的な利点もあります。

  • 必要のないパッケージのコードをダウンロード、コンパイル、リンク、インストール、信頼、およびライセンス供与する必要はありません。
  • 必要のないパッケージの依存関係をダウンロードしたり、ライセンスを取得したりする必要はありません。
  • 名前とメタデータがプロジェクト全体ではなく個々のパッケージに固有のものである場合、パッケージをより簡単に検出できます。

また、ユーザーが最終的にすべてのパッケージに依存することになった場合でも、いくつかの利点があります。

  • パッケージが異なれば、メンテナーやリリーススケジュールも異なる場合があります

潜在的なメリットを実際に実感できるユーザーがいると思うかどうかに基づいて決定する必要があると思います。したがって、決定は主に次の質問への回答に依存すると思います。

  • 他の部分よりも頻繁に変更されるプロジェクトの部分はありますか?
  • 他の部分よりも多かれ少なかれ信頼されているプロジェクトの部分はありますか?
    (たとえば、core パッケージと contrib パッケージ)
  • 多くの追加の依存関係があるが、すべてのユーザーが必要としないプロジェクトの一部はありますか?
    (たとえば、別のプロジェクトへのインターフェース)
  • プロジェクト全体の目的とは無関係に再利用できるプロジェクトの一部はありますか?
    (たとえば、メイン プロジェクトで使用されるコンビネータ ライブラリ)
  • ユーザーに特定のライセンスを (直接または依存関係を介して) 使用することを強制するプロジェクトの一部はありますが、すべてのユーザーには必要ありませんか?

最後に、cabal には「1 つのパッケージ」と「多数のパッケージ」の中間点があります。1 つの cabal パッケージには、1 つのライブラリと任意の数の実行可能ファイル、テスト スイート、およびベンチマークの両方を含めることができるからです。これは、別の方法ではパッケージの分割につながる 1 つの重要な理由をカバーしています: ユーザーは、パッケージを使用するためだけにテスト ライブラリに依存する必要はありません。

于 2013-08-26T07:06:03.653 に答える