Snapcraft Summit モントリオール

2019年6月19日

Brian J. Cardiff

Snapcraft Summit モントリオールは、2019年6月11日から13日にかけて開催され、様々なオープンソースプロジェクトの人々が集まり、サミットがなければはるかに多くの時間とリソースを必要としたであろう、円滑な方法で開発と作業を行いました。共通の目標は、snapcraft.ioストアにおける各プロジェクトのプレゼンスを向上させることでした。さらに、様々なプロジェクトの背後にいる人々と出会い、過去の経験や現在のアイデアを共有することができました。

日々、プロジェクトは着実に更新されました。プラットフォームに慣れていない人もいれば、改善や問題解決を求める人もいました。また、閉じ込め機能、ストアを活性化させる様々な要素について学び、それらを統合するための第一歩を踏み出した人もいました。毎日、約40の参加者による大規模な状況確認が行われ、その概要はforum.snapcraft.ioに投稿されました。

Crystal自体の技術的な変更点について説明する前に、今後の提案に影響を与える可能性のあるチャット、アイデア、作業を共有した人々について言及したいと思います。**rustup**のDaniel Silverstone氏、**TravisCI**のAna Rosas氏とMaría de Antón氏、**Julia**のAlex Arslan氏とJeff Bezanson氏、**NixOS**のGraham Christensen氏、そして**Snapcraft**のSergio Schvezov氏です。彼らと会うことで、プロジェクトの側面、課題、そして明確には見えない解決策について、より深く理解することができました。彼ら全員に会えたことは、非常に有意義でした。

新機能

Crystalは、10のLinuxディストリビューション（そして増加中…）に適用される新しい公式配布方法をsnapcraft.io/crystalで提供しています。
Crystalアプリケーションは、snapとしてパッケージ化および配布できます。
ナイトリーネイティブパッケージのインストールが簡単になりました。
crystal: nightlyが指定されている場合、TravisCIは上記の方法を使用します。

Crystal snap

新しいsnapcraft.io/crystalページで、snapのインストール手順を確認できます。

ストアにはチャネルという概念があり、_edge_、_beta_、_candidate_、_stable_バージョンでのリリースプロセスをサポートしています。

CIスクリプトは、毎晩_master_の内容をedgeチャネルに公開するように更新されました。そのため、ナイトリーはedgeチャネル、crystal-lang/crystal:nightly Dockerイメージ、およびビルド自体の成果物で利用できるようになりました。

新しいバージョンをタグ付けしてリリースすると、パッケージはedgeチャネルでも利用できるようになり、手動でstableチャネルに移動されます。今のところ、betaとcandidateチャネルは使用される予定はありませんが、将来的に使用できる可能性があるのは素晴らしいことです。

Crystal snapは_classic_閉じ込めレベル（詳細は後述）で実行されるため、Ubuntuパッケージのターミナルからのインストールは次のとおりです。(コマンド省略)

$ sudo snap install crystal --classic        # For stable releases
$ sudo snap install crystal --edge --classic # For nightly releases

TravisCIとの統合

Travisは、さまざまな言語と構成をサポートするために多くのことを処理する必要があります。新しいリリースも考慮して、より統一されたインストール方法があれば、人的およびコンピューターのワークロードが大幅に軽減されます。

Travisはsnapを通じて言語のサポートを開始することを熱望しており、私たちはナイトリーの可用性を再確立することを熱望していました。

(ツイート埋め込み省略)
— Brian J. Cardiff (@bcardiff) 2019年6月12日

今後、travis.ymlファイルでcrystal: nightlyを使用すると、edgeチャネルのsnapが使用されます。数か月間は、crystal: latestは、現在パッケージリポジトリでホストされている.debパッケージを引き続き使用します。最終的には、stableチャネルのsnapが使用されます。

追加の利点として、CIビルドからのトラフィックがパッケージリポジトリに発生しなくなります。

Crystalアプリをsnapとしてパッケージ化する

snapcraft#2598 ~~がマージされ、リリースされると~~ (編集: Snapcraft 3.7でリリースされました！)、アプリケーションをパッケージ化するsnapのビルドが簡単になります。 snapcraftに慣れていない場合は、紹介記事をご覧ください。

ターゲット、依存関係などを宣言するshard.ymlがあると仮定します。

name: hello

targets:
  hello:
    main: src/hello.cr

# ... stripped ...

すべての部分を宣言するための基本的なsnapcraft.yamlファイルは次のようになります。(yamlファイル記述省略)

name: crystal-hello
version: "1.0"
description: Create the hello snap
summary: Create the hello snap

grade: devel
confinement: strict

apps:
  crystal-hello:
    command: bin/hello

parts:
  crystal-hello:
    plugin: crystal

生成されたsnapをインストールした後、$ crystal-helloは./bin/helloを呼び出します。もちろん、名前を調整してcrystal-プレフィックスを回避することもできます。

.snapをビルドすると、次のことが起こります。

$ shards install --productionで依存関係をインストールします.
$ shards build --productionですべてのターゲットをビルドします.
最終的な.snapに./binにあるすべての実行可能ファイルをパッケージ化します.
これらのバイナリを実行するために必要なすべてのリンクされたライブラリをパッケージ化します（lddで検出されます）

アプリがデフォルトでは使用できないCライブラリを必要とする場合、build-packagesとしてリストする必要があります.

待てない場合は、PRコードを取得してローカルプラグインとして使用できます.

crystal snapの技術的な詳細

Crystal snapの開発を開始するにあたり、_strict_閉じ込め下で動作するようにしようとしました。strictとして機能させるための課題は、ホストとsnapのライブラリとツールチェーンをどのように共存させるかです。

snapをインストールする場合、宣言できるパッケージの依存関係はありません（.debパッケージのように）。そのため、スムーズな初期エクスペリエンスを得るためには、すべてのライブラリがデフォルトで含まれている必要があります。

コンパイルするプログラムがより高度になったり、シャードライブラリがCライブラリにリンクされるとすぐに、ユーザーは、それらのライブラリをどのように見つけるかに関するパッケージングの抽象化リークに対処する必要があります。

それが、_classic_閉じ込めモデルに固執する主な理由です。注意点は、Linuxディストリビューションのネイティブパッケージをインストール後の手順として使用できるようにする必要があることをユーザーにどのように知らせるかです。

現在の解決策は、snapでインストールされたcrystalコマンドが、実際にはコンパイラが単純なプログラムで正常に使用できるかどうかを確認するラッパーであるということです。そのチェックで問題が発生した場合、必要なパッケージに関するメッセージが表示されます。

この作業中に、CircleCIのsnap サポートに関する更新を行い、彼らの対応は素晴らしいものでした。

バージョン管理

ストアはチャネルと呼ばれる概念で動作します。各チャネルには単一のバージョンが利用可能です。チャネルのフルネームは<track>/<risk>/<branch>で、デフォルトのトラックは_latest_と呼ばれます。

前述のように、最新のリリースはlatest/stableチャネルで、ナイトリーはlatest/edgeチャネルで利用できます。オンデマンドでlatest/edge/<feature-branch>を提供できるようにCIを既に設定しています。

Crystalは1.0に達していませんが、このスキーマで十分です。最新の安定版リリースと将来のバージョンにアクセスできます。

ストアでsemverに従うプロジェクトの明示的なバージョンの可用性をどのように処理するかについて、いくつかの議論がありました。一般的なコンセンサスは、各Major.minorリリースに対して_トラック_を作成し、最新のMajor.minor.patchのみをストアで利用できるようにすることです。このスキーマでは、一部のプロジェクトは、ユーザーに明示的な決定を強制するために、latestトラックを空のままにする場合があります。どのスキーマに従うかはまだ未定です。

Canonical、Travis CI、そして関係者全員に、素晴らしい一週間をありがとうございました！