パッケージ管理

💡 お知らせ: このドキュメントはAIによって翻訳されています。表現に違和感がある場合は、原文（英語）を参照するか、翻訳にご協力ください。

自明でない Flix プロジェクトには、必ず flix.toml という manifest(マニフェスト)を用意すべきです。マニフェストには、プロジェクトとその依存関係に関する情報が記述されます。

最小構成のマニフェストは次のような形式です：

[package]
name        = "hello-library"
description = "A simple library"
version     = "0.1.0"
flix        = "0.35.0"
license     = "Apache-2.0"
authors     = ["John Doe <john@example.com>"]

注意: flix フィールドはまだ使用されていませんが、将来的に使用される予定です。

Flix の依存関係を追加する

マニフェストには、他の Flix パッケージへの依存関係を追加できます：

[dependencies]
"github:flix/museum"              = "1.4.0"
"github:magnus-madsen/helloworld" = "1.3.0"

注意: Flix では、バージョン番号は SemVer に従う必要があります。

Maven の依存関係を追加する

マニフェストには、Maven パッケージへの依存関係を追加することもできます：

[mvn-dependencies]
"org.junit.jupiter:junit-jupiter-api" = "5.9.2"

依存関係解決を理解する

Flix の依存関係解決(dependency resolution)は、次のように動作します：

1. Flix は flix.toml を読み込み、Flix パッケージの依存関係の推移的な集合を計算します。
2. Flix はこれらの Flix パッケージをすべてダウンロードします。
3. Flix は各パッケージを調べて Maven の依存関係を特定し、それらをダウンロードします。

例で説明しましょう。次のような依存関係を持つ Flix パッケージがあるとします：

[dependencies]
"github:flix/museum"              = "1.4.0"

Flix を実行すると、次の出力が得られます：

Found `flix.toml'. Checking dependencies...
Resolving Flix dependencies...
  Downloading `flix/museum.toml` (v1.4.0)... OK.
  Downloading `flix/museum-entrance.toml` (v1.2.0)... OK.
  Downloading `flix/museum-giftshop.toml` (v1.1.0)... OK.
  Downloading `flix/museum-restaurant.toml` (v1.1.0)... OK.
  Downloading `flix/museum-clerk.toml` (v1.1.0)... OK.
  Cached `flix/museum-clerk.toml` (v1.1.0).
Downloading Flix dependencies...
  Downloading `flix/museum.fpkg` (v1.4.0)... OK.
  Downloading `flix/museum-entrance.fpkg` (v1.2.0)... OK.
  Downloading `flix/museum-giftshop.fpkg` (v1.1.0)... OK.
  Downloading `flix/museum-restaurant.fpkg` (v1.1.0)... OK.
  Downloading `flix/museum-clerk.fpkg` (v1.1.0)... OK.
  Cached `flix/museum-clerk.fpkg` (v1.1.0).
Resolving Maven dependencies...
  Adding `org.apache.commons:commons-lang3' (3.12.0).
  Running Maven dependency resolver.
Dependency resolution completed.

これは、flix/museum が次のような依存関係ツリーを持っているためです：

• flix/museum は以下に依存します：
  • flix/museum-entrance は以下に依存します：
    • flix/museum-clerk
  • flix/museum-giftshop は以下に依存します：
    • flix/museum-clerk
  • flix/museum-restaurant は以下に依存します：
    • org.apache.commons:commons-lang3

セキュリティ

サプライチェーン攻撃(supply-chain attack)のリスクを軽減するため、すべての依存関係には security context(セキュリティコンテキスト) が設定されます。これは、明示的に設定しなかった場合でも同様です。security context は、依存関係が使用できる言語機能を制御します。より広い security context を許可すると使える機能は増えますが、その分サプライチェーン攻撃のリスクも高まります。

security context は次のように定義されています：

各依存関係の security context は、マニフェスト内で次のように設定できます：

[dependencies]
"github:flix/museum"              = { version = "1.4.0", security = "plain" }
"github:magnus-madsen/helloworld" = { version = "1.3.0", security = "unrestricted" }

security context は推移的に適用されます。つまり、ある依存関係の security context は、その推移的依存関係にも適用されます。ただし、依存関係がより制限の強い security context を明示的に宣言している場合は例外です。複数の依存関係が同じライブラリを必要とする場合、そのライブラリには、要求された中で最も制限の強い security context が適用されます。

推奨されるのは、security context を指定せず、デフォルトの plain を使うことです。これが柔軟性と安全性の最も良いバランスを提供します。unrestricted は、（推移的な）依存関係が何でもできてしまうため、可能な限り避けるべきです。unrestricted な依存関係を含むコードは、ビルドやコンパイルをするだけでもサプライチェーン攻撃にさらされる可能性があります。

エフェクトを必要とする Flix ライブラリの作者である場合のベストプラクティスは、IO エフェクトを直接使うのではなく独自のカスタムエフェクトを導入し、ライブラリを 2 つのパッケージに分割することです：

このアプローチには、次のような利点があります：

• ほとんどの機能が、信頼できる plain の security context にとどまります。
• 安全でないコードは webserver-lib-handlers に隔離されるため、レビューが容易になります。
• 提供されたハンドラを信頼できない場合、ユーザーは自分でハンドラを実装できます。