Google が Unity 向け SDK の配布・バージョン管理に Unity Package Manager(以下UPM)を使うようになっていたりと、ようやく今時の UPM 事情に追いついたので、ここではその辺の情報のまとめを。
UPM 対応パッケージをつくるには? エディター拡張の管理に UPM を使ってみたら? 等の細かいお話についてはこちら。
もくじ
グーグルの Unity 向け SDK が UPM 対応に
※ Scoped Registry なら検索も出来るしバージョンも選べる
Google for Games Developer Summit March 2020 でちらっと Scoped Registry について触れられていて、今後は UPM の Scoped Registry での運用に移行するようで。
UPM の Scoped Registry は今後発展していきそうな印象。ローカルパッケージや Git をパッケージとして扱う、という機能は残ってるけどもう息してない、、、という感じ。
Scoped Registry が設定された manifest.json
をバージョン管理ソフトで共有すれば、あとは UPM の UI から必要なバージョンをダウンロードするだけになる。ハズ。簡単。
↑ の対応バージョンは Unity 2018.4 以降。
-
Unity - Manual: Scoped package registries
- マニュアル的には Scoped Registry の対応は 2019.1 から(Versions without this page だからページがないだけか)
Google のは認証不要で大っぴらに公開だけど、認証アリのプライベートな Scoped Registry を使う場合は、Unity 2019.3.4f1 以降が対応しているとか。
Google 製レジストリ追加ツール
manifest.json
を書き換えてくれるインストーラー(.unitypackage
)が用意されてる。
UPM ウインドウの「+」ボタンに Add Custom Registry を追加してくれれば、今後はこういうインストーラーも不要になる。
Scoped Registry について
パッケージ管理システム(npm: Node Package Manager)のレジストリ。
- パッケージの追加、じゃなくてレジストリの追加が出来た方が諸々良い感じなんじゃ? と思って調べたら、Unity 2019.1 から機能が追加されている。
-
Unity - Manual: Scoped package registries
- Unity 純正のパッケージ同様、検索やバージョン切り替えにも対応してる
- レジストリといえば GitHub Packages ってリリースされましたね。
-
Unity - Manual: Scoped package registries
- 認証も行けるらしい。(Unity 2019.3.4f1 以降)
- 自前サーバーで行くなら @Shiranui_Isuzu さんの方法。
GitHub Packages について
Scoped Registry としては GitHub Packages が使えそう。他には公式マニュアルに記載されている Verdaccio というローカルに立てるサーバーソフトウェアがある。
--
GitHub Packages は基本無料で使える、ストレージ容量や転送量なんかで料金が発生するタイプのサービス。
GitHub Packages の注意点
GitHub Packages でパブリックに公開した npm パッケージは、消すのが容易ではなさそう。
技術的な問題で削除できないんではなく、パッケージ間の依存関係が崩れるから消さない、という思想的な理由による方針なので、間違えたからーーだと即座に削除対応はしてもらえない、かも?
パブリックパッケージの削除について
パッケージに依存しているかもしれないプロジェクトが壊れることを避けるために、パブリックなパッケージ全体、あるいはパブリックなパッケージの特定バージョンを削除する事はできません。
法的な理由、あるいはGDPR標準への準拠のような特別な状況下では、GitHub Supportに対してパブリックパッケージを削除してもらうよう、連絡フォームを使って頼むことができます。
--
GitHub Teams 無料化で、とりあえず作ってある Organization のリポジトリもプライベートにできるようになったので、レジストリにはプライベートレポジトリを使う。
その他雑記
共通基盤的な、プロジェクトを跨いで使う諸々を Unity プロジェクトでどうやって共有するか。
--
クラウドストレージやらリポジトリやらを同期したローカルフォルダーを各人の Unity プロジェクトで参照するように設定する、なんてやるよりは、レジストリを建てて配信した方が良さそうだけど、Assembly Definition が何というか、邪魔なんだろうな。
Scoped Registry は .asmdef
無しでもおっけ、とか出来るともっと流行りそう。
Assembly Definition について ↓
--
Scoped Registry を使って、シェーダーを UPM 対応パッケージとして配信するのは良さそう。Assembly Definition 云々の影響がほぼ無さそうだし。
--
Unity を使ってる = Git も使ってる率高めだから、もっと単純に *
な .gitignore
を持った Extensions
フォルダを Assets/
以下に作るようにして、そのフォルダ内にリポジトリをクローンする方法が一番… かも?
Assets/
に余計なファイルは増えるけど、畳んでおけば UI 上は邪魔にはならないし .asmdef
もいらない。ファイルの削除・移動を含んだ更新も追っかけられる。
GitHub の Teams も無料化されたので、とりあえずだから、で始まって結果的に個人所有のプライベートレポジトリに物がある、も避けられる状況になってる。
--
配るときに限った話。コピーが散らばることになるので、各プロジェクトでファイルの変更もするような場合は、自分で全部確認して必要に応じてコミットする必要アリ。
--
エディター拡張はそもそもインストール、という工程自体を無くしたいからホームディレクトリの Unity / EditorExtensions
と Unity / <Version> / EditorExtensions
フォルダーを Unity は常に読み込む、.dll
化も .asmdef
も不要、みたいになってくれると良い。
--
とか考えていくと、プロジェクトに必要なシンボリックリンクが無かったら作ったり最新のリリースを確認しに行ったり同期したり、使うバージョンを変えたら必要に応じて Unity 自体を更新したり、な環境セットアップ系のバッチコマンドを用意した方が良いじゃね、自由度も高いし、というよくある感じの結論に。
--
以上です。お疲れ様でした。