ドキュメントなどを別のリポジトリに移動する提案

[y-yu]

はじめまして。
リポジトリを拝見させていただきましたが、ascmac.pdfなどのドキュメントがリポジトリに混ってしまっているように思われます。やや原理主義のような気もしますが、Gitにこのようなファイル（成果物）を置いてしまうと、リポジトリのサイズが巨大になってしまう可能性があると思います。
そこで、次のようにドキュメント専用のリポジトリを作り、ドキュメントはその場所に置くというのはどうでしょうか？　勝手ながら、ドキュメント用のリポジトリのサンプルを私の方で作らせていただきました。

https://github.com/y-yu/platex-documents

ドキュメントはこのplatexリポジトリをTravis CIで自動コンパイルするように設定してあります。
また、platex.ltxなどドキュメント以外の成果物もこのリポジトリからは除外して、成果物を置く専用のリポジトリに移動させてTravis CIなどで自動デプロイした方がよいかもしれないです。

以上、読んでいただきありがとうございました。

[aminophen]

ご意見どうもありがとうございます。ただいま #10 でも開発方針の議論を始めたばかりでして、今後の pLaTeX / upLaTeX 開発にあたりどうするのがいちばん効率がよいのか考えている最中です。

現在の GitHub リポジトリは

[1] ソースファイルたち（主に dtx / ins）
[2] ソースから strip されるパッケージ・クラスなど（主に ltx / sty / cls など）
[3] ソースから build される PDF ドキュメント（pdf）

をすべて置いた状態で、そこからリリース時に create_archive.sh を使って

[4] CTAN へアップロードする [1] + [3] のセットを含む zip ファイル
[5] TeX Live への import に使う [1] + [2] + [3] を全て含む .tds.zip ファイル（Karl さんから要望）

を作る、という構造になっています。

別のリポジトリに分けてまで管理すべきものでもない気がしているので、「リポジトリを小さくする」という観点では、本家 LaTeX の subversion リポジトリが採用している

• リポジトリには [1] だけを置く
• build.lua を使うと [2] + [3] が自動生成して [4] や [5] も出来る

という方法に移行することは可能だと思います。ただそうしてしまうと、このコメントで書いたような「コミット前後のソース (dtx) から strip されたファイル (ltx) の差分をみて、ソースの編集ミスがないことを追認する」ということができなくなってしまうな、とも思っています。

[aminophen]

Travis CI のしくみ（というか、そもそもどんなものなのか）がまったくわからないのですが、pLaTeX のドキュメントの build 要件として「事前に fmtutil で platex.fmt を作り直す」がありますが、それは可能でしょうか？（必須ではない場合もあるかもしれませんが、フォーマット再作成が必要な状況が生じた場合に破綻しないように、です）

[y-yu]

@aminophen さん。

ご返答ありがとうございます。

• リポジトリには 1. だけを置く
• build.lua を使うと 2. + 3. が自動生成して 4. や 5. も出来る

私はこれに賛成です。やや原理主義かもしれないですが、リポジトリに成果物があるのはやや微妙だと考えています。

ただそうしてしまうと、このコメントで書いたような「コミット前後のソース (dtx) から strip されたファイル (ltx) の差分をみて、ソースの編集ミスがないことを追認する」ということができなくなってしまうな、とも思っています。

このことも確かにそうなので、議論の余地がまだあるので、直ちにはできないと思いました。

また、Travis CIについて何も説明していませんでしたので、Travis CIの説明をさせていただきます。Travis CIとは簡単に言えば、コンパイルやテストを実行するため利用できる仮想環境です。.travis.ymlというファイルに、リポジトリをコンパイルするための設定（たとえば、利用するOSや事前にインストールするライブラリ、ビルドのコマンドなど）を書き込み、それをGitHubにプッシュするという流れです。すると、Travis CIがGitHubへのプッシュに反応してリポジトリをクローンし、.travis.ymlの内容に従ってリポジトリをコンパイルし（場合によっては）成果物をデプロイすることになります。

そして、私が用意した.travis.ymlは次のようになっています。（ここに記述したコマンドが、おおむね上から下に向って実行されます）

https://github.com/y-yu/platex-documents/blob/master/.travis.yml

これは次のような仕事を行っています。

1. ビルド環境をOSXにする
2. BasicTeXをインストールする
3. sudo tlmgr install collection-langjapanese collection-fontsrecommendedなどを実行する
4. make clean（platexリポジトリにPDFファイルが含まれているので、事前に消しています）
5. make all
6. 鍵などを設定し、PDFファイルをGitにアップロードする

また、

pLaTeX のドキュメントの build 要件として「事前に fmtutil で platex.fmt を作り直す」がありますが、それは可能でしょうか？

これも、.travis.ymlに追記すれば可能であると思います。

[y-yu]

参考までに、さきほどTravis CIでドキュメントなどのコンパイルを実行したログを貼っておきます。
https://travis-ci.org/y-yu/platex-documents/builds/142121727

[aminophen]

私はこれに賛成です。
[...]
このことも確かにそうなので、議論の余地がまだあるので、直ちにはできないと思いました。

ソースと build.lua だけを置いておく方法は、「リポジトリが小さくなる」だけでなく「本家 LaTeX と同じ方式をとれば外部の人にもわかりやすい」という利点もあると思います。

一方で、この方法には「strip されたファイルの差分を追認できなくなる」以外の欠点として「TeX Live の svn diff が大きくなりがちなこと」があります。LaTeX の場合はソース (dtx) が一切変わっていない PDF も rebuild されて必要以上に大きくなっているのですが、いまの pLaTeX は最低限に保てています。GitHub のスマートさと TeX Live svn のスマートさが両立するとよいのですが…もう少し考えます。

Travis CIの説明をさせていただきます。
ログを貼っておきます。

少しわかってきました。ありがとうございます。

[aminophen]

手始めといいますか、 bdd27ac で Makefile のデフォルトビルドから pdf を外しました。ただし、ドキュメントをコンパイルしてみないと、文法チェックや \CheckSum 確認が難しいので、dvi まではビルドするようにしています（.gitignore に拡張子 .dvi が登録されていますので、git にいちいち反映されない算段です）。make default がデフォルトですが、make all とすると pdf ごとビルドします。pdf をリポジトリから削除することは、とりあえず実行せずそのままにしてあります。

本格的に「生成ファイル群を別のリポジトリに移行」とするのであればもっと進める必要がありますが、一時的にこれでいこうと思います。（pdf が差分に入らなくなるだけで結構軽くなると思ったので…）