Swift Package Managerについて知る

(音楽)

(拍手) Getting to Know Swift Package Managerへようこそ 私リック･バラードと ボリス･ビューグリンが― SwiftのPackage Managerを 紹介します SwiftPMとも呼びます 今回はオープンソース プロジェクトに注目し― 他のツールには触れません しかし内容は盛りだくさんです SwiftPMはSwiftのエコシステムに 簡単にソースコードを配信できます 今回の議題は目標とデザイン そして未来への指標です

まず新しいPackage Managerを 作った理由をお話ししましょう 使い方を説明したあと― デザインと特性に移ります それから未来の指標に触れ― SwiftPMのオープンソースの工程と 関わり方についてお話しします

パッケージマネージャは コードのシェアと再利用に最適です では なぜSwift専用が必要なのか？

Swiftの言語は クロスプラットフォームで― それに対応した ビルドツールが必要でした Swiftの全プラットフォームで コード設定が簡単になります SwiftPMのビルドシステムは ソフトフェアを設定し― ビルドとテストを行い 実行をします

またSwiftライブラリを 誰とでも簡単に シェアできるようにするため 基本のパッケージマネージャを 提供しています 共通基準を明確にするのに 役立つでしょう これはエコシステムと Swift自体に好影響です

皆さんも 追加したい機能があるでしょう コアライブラリへの 変更は慎重に行い― 精選されたAPIを保っています 優れたパッケージマネージャは コアライブラリに入らずに― 追加機能をパッケージ化します 良いアイデアはコミュニティ内で 注目され 徐々に規格化されます

パッケージマネージャの 開発によって― Swiftのパワーと哲学を生かせます SwiftPMはSwiftに 書き込まれています Swift言語とコアライブラリの プロジェクトにも関わることで― コードがより 使いやすくなっています

SwiftPMはオープンソース プロジェクトの一環で― Swift.orgとGitHubに 詳細が載っています “Package Manager”から 読むのをお勧めします

他のSwiftツールもSwift.orgで ダウンロードが可能です また最新のXcodeの リリースも含まれます

使い方を説明するため ボリスがSwiftPMの 基本をお見せします (拍手)

ありがとう では使い方の説明です

SwiftPMには４つの コマンドラインツールがあります “swift build”は パッケージをビルドし― “swift run”は実行をします “swift test”はテストを行い― “swift package”はビルド不可の オペレーションを実行します

パッケージは Gitリポジトリに保存され― 分岐はGitタグにより表されます

次にパッケージ作成が どれだけ簡単かをお見せします

ターミナルで ディレクトリを作成します “helloworld”がパッケージ名です ディレクトリに切り替え “swift package init”を実行 タイプは“executable”

これでSwiftPMが 基本構成を作成します Finderを開いて― 詳しく見てみましょう

“Package.swift”は パッケージの構成を表します “README”もあります

“Sources”には サブフォルダの“helloworld” “main.swift”が実行ファイルです “Tests”は ユニットテストを行えます

ターミナルに戻り―

“swift run”とタイプして パッケージを実行します これでコンパイルされ リンクするとhelloworldが 出力されます

今度はもっと複雑な パッケージを見てみましょう SwiftPMの基本コンセプトも 併せてお話しします まずは― 実行してみましょう トランプのカードが ランダムに出力されます

ではスライドに戻り― 基本コンセプトをお話しします

パッケージは３つに分かれます 依存関係と―

ターゲット

そして製品です

それぞれの詳細を見ていきます

新たな機能を開発する際に 使うのが依存関係です

各依存関係が１つ以上の 製品を提供します 例えばパッケージの ライブラリなどです

マニフェストファイルで 依存関係を見てみます

各々でソースの場所があり―

バージョンもあります

ターゲットは パッケージの基礎です モジュールかテストスイートに ソースファイルが― どうビルドされるかを表します

ターゲットは同じパッケージ内で 依存し合い―

別のパッケージの製品を 依存関係として宣言します

製品はライブラリで実行され―

１つ以上のターゲットから 成っています

製品を定義することでパッケージは ライブラリを提供します デフォルトでは ライブラリのタイプを宣言しません SwiftPMが用途に合わせて選びます スタティックかダイナミックの 宣言は可能です

マニフェストでターゲットを見ます

３つのターゲットがあります

“libdealer”はメインの機能の 実装が含まれています 依存関係は “DeckOfPlayingCards”です これは先に宣言した依存関係です

“dealer”は それに依存して コマンドラインツールを提供

最後に“testTarget”があります ユニットテストが可能です

また２つの製品があります

ライブラリはターゲットの “libdealer”に対応し これによりライブラリでの 実装が可能になります

次の実行可能な対象は “dealer”に依存させ― コマンドラインの 使用を可能にします

最後に新しい機能を追加する際の パッケージの使い方です

ターミナルウィンドウを開きます “Package.swift”を開き―

新たな依存関係を加えます

ここではSwiftPMです リックがお話しした Swift専用のパッケージです 不安定なAPIなので“exact”に バージョンナンバーが出ます

ターゲットの“libdealer”の 製品に依存します “Utility”と言います またターミナルコントローラという クラスがあり― ターミナルの出力に 色をつけることができます

正式なAppleのAPIではなく デモのために使用しています

ターミナルに戻ります

新しい依存関係を使うため コードは変更しました デモの事前にです これで実行すれば 結果が見られます

同じ出力ですが カラーになって楽しい感じです

最後のデモに移ります

SwiftPMのテストです これにはSwift Neoの パッケージを使います 春に公開した ネットワークライブラリです

“swift test”を実行し

“parallel”とします

並行テストなので 結果は迅速に得られます フィルターオプションもかけます

テストのサブセットを実行するので 反復して使えます

パッケージがコンパイルされ テストが実行されます あと数秒ですね

プログレスバーが出てきました 並行テストなので 結果はすぐに出ます

スライドに戻りましょう

次はSwiftPMのデザインのお話です

SwiftPMはSwiftと同じく すばやく安全で表現豊かです

高い安全性は 独立したビルド環境と 任意のコマンドの禁止に 起因しています

拡張可能なビルドエンジンで 大きな依存グラフにも高速対応

マニフェストにSwift言語を使用し 表現も豊かです また既存の プログラミング言語も使えます

次のセクションでは Swiftパッケージを作成する 工程をご説明します まずは 構造です

SwiftPMのマニフェストは Swiftを基本としています 新しい言語を学ぶ必要がないので 簡単に理解できます APIデザインのガイドラインに 従っているので親しみやすく 既存のSwiftツールを 活用することができます

マニフェストを書き込む際は 宣言型構文をお勧めします SwiftPMはソースコードが― 診断される時間と頻度を 保証しないからです スライドの左側の例では 宣言ができません 名前は生成中のものが表示されず パッケージ内で 何度か使用されています

右側は文字列定数を使って マニフェストが宣言できます 理解しやすく ターゲットが明確です

宣言型構文を使わない場合 マニフェストは複雑になります

ソースファイルは各ターゲットの 名前ごとに整頓されます これによりパッケージが 共通構造を選定しやすくなり すばやい操作を行えます

Package Managerや 他のビルドツールは ユーザの設定とPackage Managerの 規則が相反することがあります

先に述べたとおり ソースファイルは規則に基づく 場所から自動的に取得 マニフェストを編集せずに ソースファイルを更新できます

製品とターゲットは 設定の価値があります

ディスクのレイアウトと 相互参照なしでも― パッケージや定義が 分かりやすくなります またマニフェストを見るだけで クライアントも簡単に理解できます

他のプログラム言語の ソースコードもサポートしています CやC++ Objective-Cなどです これで統合が可能です しかしSwift内の同じターゲットで 言語の統合はサポートしていません

次に依存関係とバージョニングです

チャーンを避けて バグ修正ができるように セマンティックバージョニングを 使っています バージョン番号の各要素に 具体的な意味を当てはめます

メジャーバージョンは 大きな変更を表し コードのアップデートが必要です 変更とは 既存の型や メッセージの削除― 署名の変更などがあります 互換性のない バグ修正も含みます または既存のAPIの 大きな変更も含まれます

マイナーバージョンは後方互換の 機能が追加された場合で メソッドや型を 追加した時などです

パッチバージョンは後方互換性の バグ修正作成時に増加させます

クライアントはバグ修正で ソースコードを― 壊すリスクがなくなります

SwiftPMはビルド前にパッケージの バージョンを決める必要があります “依存関係解決”と呼びます SwiftPMは すべての必要条件を確認します パッケージを明確にし 互換性のある 最新のバージョンを探します

先程のデモを使って このプロセスを見てみましょう

dealerには ２つの依存関係がありました SwiftPMとトランプのカードです

SwiftPMは これらのバージョンを決定します １つ目はバージョンを 決めていたので簡単です そのタグから始めます ２つ目は構文なので マイナーまたはパッチ要素を アップデートします

この例の場合 タグは3.1.4です

プロセスは繰り返されます 次にSwiftPMは 推移的依存関係を確認します SwiftPMは これ以上することがありません

トランプは“fisher-yates”と “playing-card”に依存します

これらのバージョンも 決めなければなりません fisher-yagesは構文を 使用しているので先程と同様です タグは2.2.5となります

playing-cardは “upToNextMinor”を使っているので パッチ要素のみ アップデートされます バグ修正のみの場合 同じ構文を使用しても構いません

タグは3.0.2となりました

最後にターゲットを見ると 必須の製品を 決定したパッケージと― 組み合わせる必要があります そこでlibdealerに目を向けます SwiftPMから製品の Utilityが提供されています その他は 別の製品を提供しています

すべて終わると Package.resolvedに記録されます 決定したバージョンを メンバーにシェアするためです また一連の統合の基礎により ビルド成果を取得でき アップデートの時機が 計りやすくなります

その際はSwift Package Updateを 実行してください これはPackage.resolvedを含む― トップレベルのパッケージです 推移的依存関係に Package.resolveが含まれる場合 依存関係解決では無視できます

次はパッケージのビルドです

ビルドエンジンは llbuildを使用しています ビルドシステムのための ライブラリです 汎用と再利用可能な ビルドエンジンに優れ― 高速かつ正確な 増分ビルドが行えます Xcodeにも採用されています

オープンソースプロジェクトの 一環でもあります

すべての依存関係の明言を伴う 独立した環境では―

複雑な条件を有するパッケージでも ビルドと使用が保証されます 全パッケージを インストールせず 依存関係が明らかな パッケージが使われます また サンドボックス化を活用し 任意の場所への 書き込みを防いでいます また任意のコマンドと シェルスクリプトを禁じています ビルドグラフが 理解しやすくなり すべての入力と出力が 高速で正確な増分ビルドを行えます すべての依存関係が 確認できるからです

SwiftPMはテストも サポートしています XCTestのフレームワークに 基づいています

並行テストなので 結果はすぐに出ます テストのフィルタで― サブセットを実行し 反復して使えます

ワークフローの 特性を考えるのは コマンドラインで すべての開発を行うためです

例えばエディットモードです 特定のパッケージの 推移的な発生を上書きできます

一時的に編集が可能となり 依存関係がテストできます グラフの全パッケージの 転送は要りません

ブランチ依存関係は 厳密なバージョン要件が不要です 複数のパッケージを作る際に 便利です 開発段階の機能なので タグの公開前には バージョン依存関係を変更します

ローカルパッケージは パッケージを直接使用でき Gitリポジトリは使用しません これで作成の初期段階に複数の― パッケージを使うことができます

最後にSwiftPMとSwift言語の 新バージョンについてです

Package.swiftの マニフェストAPIも新しくなります 既存のAPIも使えます 新しいソースツールを活用する際 アップデートは不要ですし 既存のパッケージにも アクセスできます 新しいAPIでは独立して ソースコードの言語の バージョン変更ができます

どのバージョンかを確認するには Package.swiftの一番上にある swift-tools-versionを使います マニフェストを 処理するために必要な― バージョンを表示しています

各パッケージは必要なSwift言語の バージョンを宣言します コンパイラディレクティブを 使って 複数のバージョンを 選ぶことができます 異なる言語バージョンを 混ぜることも可能です

現状のSwiftPMの話をしました 次はリックから 未来の指針を話してもらいましょう (拍手) ありがとう ボリス ボリスは現状をお話ししましたが 次は未来の可能性です SwiftPMは まだ発展の余地があります

“オープンエボリューション プロセス”とは 誰でもアイデアを 提供できるということです 我々はいつでも アイデアをシェアします 計画とは無関係です SwiftPMの可能性を 知ってもらいたいのです フィードバックやコメント 独自のアイデアをお待ちしています

これから４つのテーマで お話しします SwiftPMを他のツールと 統合させること パッケージの新バージョンを 発表し展開させること 現段階以上に複雑な パッケージをサポートすること そしてパッケージの 可能性と信頼性です

コマンドライン体験は重要なので 他のツールとの統合が必要です 例えば開発環境や自動化などでです

すでにアーキテクチャで 基礎作りはしました 現在は安定したAPIがありません しかしSwiftPMの変化に 準じたツールは 現在でも選定と追加が可能です

デベロッパツールにおける SwiftPMのサポート構築について 意見を聞かせてください SwiftPMをエコシステムにと 考えています

最近 あるリクエストがありました Package.swiftマニフェストを ユーザからではなく 自動化されたツールで 編集する方法についてです SwiftPMで サポートできると考えました 使うのはlibSyntaxです オープンソースプロジェクトで 開発されたライブラリです 他のツールからSwiftの構文の 理解と操作がしやすくなります

Package.swiftマニフェストには 宣言型構文をお勧めします その理由の１つが SwiftPMがマニフェストを 理解しやすくなること これで自動的に編集されます 例えば依存関係やターゲットを 加えることです

新バージョンの公開と 製品の展開を手助けする― 機能も追加できます

今は公開する際 Gitを手動でタグ付けしています タグを検査したい場合も Gitを直接使用します これを自動化する機能が 追加できます ハウスキーピング処理や検証 その他の補助的なタスクは ワークフローに組み込まれます

セマンティックバージョニングを 正しく維持する機能も追加できます SwiftPMが新バージョンでの APIの相違点を分析でき コンパイル時間に互換しない 変更点を探せます これによりバージョンの アップデートを推奨できます

他にもパッケージの製品を 配置しやすくできます ライブラリとのリンクや 製品のレイアウトを カスタマイズしたい 場合があるかもしれません または何のパッケージかを示す バージョン情報を含みたい時や 製品内のパッケージ情報に関する コンテキストを使いたい時もです SwiftPMは これらのニーズに応えます

様々なものがビルドできますが さらに複雑なパッケージを サポートしたいと思っています

最大の課題は リソースのサポートです 画像やデータファイルなどが ある場合― 製品とともに まとめることができません コアライブラリが この春 APIを追加しました リソースの クロスプラットフォーム化です SwiftPMも このAPIを適用できます

ユーザの中には コンパイラフラグの指定など 現在は使用できない 機能を求める人もいます 安定したビルド設定モデルが 必要です 可能性としては 条件付きの設定や パッケージが得る設定値を 制御する設定などです

SwiftPMは独立した ビルド環境にあります 任意のシェルスクリプトは 実行不能です しかし ある程度の カスタマイズは必要です ユーザはカスタム言語や プロセッサを使いますし 自らの実装を実行したいでしょう 他の作業をする場合も あるかもしれません

SwiftPMなら可能でしょう 新しいツールを ビルド工程に含めたとしてもです この場合に確認することがあります 新しいツールを加えたら 出入力の依存関係を 正しく宣言します それにより正確な増分と 並行化可能なビルドを保てます

最後にパッケージの可能性と信頼性 そして管理についてお話しします

GitはTLSのような セキュリティ構造をサポートし リモートリポジトリへの 接続を確認しています それでも不正アクセスされ 悪質なコンテンツが置かれる場合も これは第三者のコードを使用する際 想定すべきリスクです しかしSwiftPMは セキュリティ機能をビルドし 所望のパッケージコンテンツを 取得できます

またビルド中のPackage.swift マニフェスト評価の― エスケープや書き込み ネットワークアクセスを回避します 現在はmacOSの サンドボックス技術を使用 他のプラットフォームも 強化を考えています

ユーザはフォークの しやすさを求めます 一方のパッケージを カスタマイズしたい場合や パッケージを取得したオリジナルの URLをオーバーライドして 自分で コントロールしたい場合もあります オリジナルに頼る 必要がないようにです

最終的に インデックスを持つでしょう ネームスペースの提供や パッケージの発見のしやすさに加え パッケージの品質測定法も 加えたいと思っています またはパッケージの信頼性を 精査する方法です

これらは可能性の一部に過ぎません 興味があればフィードバックや アイデアなどをお待ちしています SwiftPMを 最高のツールにしましょう

そのためにSwiftの オープンソースの工程を説明します

SwiftPMはオープンソース プロジェクトの一環で swift.orgにコミュニティと プロセスの詳細があります

Swift言語の エボリューションプロセスでは 誰でも試案を提出できます SwiftPMの新しい機能や 変更についてです

試案を完成させて提出する前に フォーラムの― Package Managerに訪れ アイデアをシェアしてください フィードバックで アイデアがさらに磨かれます

もう少し控えめに 参加したいならば bugs.swift.orgに 多くのアイデアがあります 特にStarterBugの タグ付けバグを見てください SwiftPMはSwift言語なので チェックは簡単です

SwiftPM使用時に バグを見つけたら bugs.swift.orgに ファイルしてください トラッキングも可能です

SwiftPMはSwiftプロジェクトの 恩恵を得ています ポーリングが自動的にビルドされ テストが実行されます SwiftPMのコードには 立派なテストがあり― その基礎構造が役立ちます

最新版はSnapshotsのToolchainから ダウンロードできます swift.orgで定期的に アップデートしています

コミュニティの成長は 喜ばしいことです 180人以上がバグ修正や 新しい機能に貢献しています エコシステムも成長を続けています クロスプラットフォームやGitHubの パッケージとも連動し 皆は製品に集中し 他は パッケージ依存関係に任せられます 未だ発展段階ではありますが ２点ほど試してみてください コマンドラインユーティリティと ライブラリです Swiftをサーバで成長させるのです サーバ側では SwiftPMを頻繁に使用しています ウェブやバックエンドの開発の― フレームワークとともに 成長しています これらのクロスプラットフォームの 発展にSwift言語は最適です

コマンドラインユーティリティや ライブラリの作成でも構いません 始めは“swift package init”を 実行するだけです 新しいことに挑戦したければ 試してみてください 貢献いただけるなら フォーラムで話し合いましょう 話をしたければ 明日の午後３時にラボにいます

これからコミュニティで 一緒に何ができるか楽しみです あなたの貢献が助けとなり コミュニティにも好影響を与えます ありがとうございました (拍手)