---
# System prepended metadata

title: 再現性に関する議論 ワークフローミートアップより

---

# 再現性に関する議論 ワークフローミートアップより

Slack workflow-meetup-jp の \#package チャンネルでの
話題になった議論について忘れないうちにメモ


1. Docker で救いきれないものの話
2. ソフトウェアのパッケージングの話 (Dockerfile 関係はここだと思っている)
3. パッケージングシステムの話 (Docker, Singularity, Nix など)
4. ソフトウェア品質の話 (テストなど)
5. ソフトウェアのポータビリティの話 (エンディアンなど)
6. 再現性とはなにか、どう定義するかという話 

## 石井コメント

上記のどこかにいれたいが、少し違うレイヤーの可能性もあるもので、議論したいもの。できれば作り方や切り出し方の指針またはがあるとよい。原則があれば原則

- コマンドラインオプションの作り方、受け方
- APIの切り出し方

## 丹生コメント

複数のトピックにまたがる問題もあるのがややこしい…
- ソフトウェアの品質は、再現性にも影響がある場合がある
    - 影響がある例
        - 特定のエンディアンを想定している
            - チップセットが変わると動かないかもしれない
    - 影響はない例
        - 特定のオプションを渡すと問答無用で落ちる
            - 問答無用で落ちる、という結果が毎回得られる場合、再現性はあるとみなしてよいはず (実用的ではないが)
- ソフトウェアの品質は、パッケージングの難易度にも関係する場合がある
    - コンテナ化しにくい
    - CWL 化しにくい (これもある種のパッケージング)
        - CWL 化という文脈だと、ユーザビリティ的な視点からのソフトウェア品質が関係してくる
            - 例
                - コマンドラインのオプションなどの API が変態的
                - 引数に現れていない入力を暗黙的に要求する or 指定してないファイルやディレクトリに何かを吐き出している
                - 出力ファイル名がランダム (or 時刻など、固定値ではない) 以外を選択できない
            - 雑方式で CWL 化できるか、は指標の一つとして使えそう？
- 全部同時に(or トピックを明示せずに)話をしてしまうとおそらく議論が発散してしまう

### 1 について
- 実際問題、Docker で再現性の問題などをどの程度救えてどの程度救えていないかは興味がある

### 3 について
- 個人的にはワンバイナリ的なアプローチが一番正しそうな気がしている
    - ＋ non-root かつデーモンレスな方法で、パッケージが(展開なしに)動かせれば一番いい
- 解析系のソフトウェアに限定すると、ユーザーサイドで依存性解決(+ビルド作業)をさせるべきではないと考えている
    - pip, conda, venv など、どう考えても闇が深すぎる
    - apt などもこの用途では不適 (依存パッケージ全部のバージョン指定なんて実践してる人いるのか)

### 4, 5 について
- できれば他のトピックとは分けて議論がしたい
    - パッケージング以降の話は package maintainer などが頑張る問題
        - パッケージを作る人はある程度ベストプラクティスなどに従ってくれるはず
        - パッケージのリポジトリに入る前にレビューが入るはず
    - ソフトウェアの品質(ポータビリティ含む)は、個別の開発者の問題
        - 全ての開発者のリテラシーを上げることで再現性の問題を解決する、という手法は現実的ではないと考えている
        - 人類を滅ぼすしかない
- 自分の(or 身近な)ソフトの品質を上げる文脈での議論は普通にしたい

### 6 について
- Docker による再現性の前提は「ファイルとディレクトリ構成が完全一致してれば実行結果も一致するはず！」だと考えている
    - そのため「ファイルとディレクトリ構成が完全一致しているかどうか」(i.e., コンテナイメージIDが一致しているかどうか)という定量的な指標によって間接的に再現性の評価ができた
        - Docker for * などは軽量 VM 上でコンテナを動かす方式のため、例えば ARM ベース mac でも普通に x64 コンテナの動作は可能 (原理的には)
        - この単純な指標でも、実際にある程度の再現性が確保できることが判明した、というのが Docker の偉大なところだと考えている
    - が、マルチアーキテクチャイメージの登場でその前提が崩れてしまった
        - アーキテクチャが異なるとイメージも異なる (== コンテナイメージIDが一致しない)
        - 当然バイナリも異なる場合がある (== 一部ファイルが一致しない)
- 定量的に評価できる定義が望ましい
    - うまくやらないと、心温まる手作業から抜け出せない (自動化できない)

## 石井コメント２

- 忘れてはいけない観点として「お手軽さ」がある
    - 各種パッケージングシステムは、登場当初、相当お手軽にしてくれた印象がある
    - dockerはこの点をさらにお勧めてくれた感じはする。
        - 途中仮想マシン時代があり、これはこれでよかったとはおもっているが、やはり手軽度はdockerではないだろうか。
    - ただし、「お手軽さ」と「再現性」に関しては、両立させることができるのか？ということも含めて考える必要があるかもしれない。
        - 個人的には、「お手軽」に「再現」してくれると非常良い気はするが、そこが実現できるかについてが今回の議論の発端であるとおもわれる。