stripe-haskellを最新のstackageに対応させたい

stripe-haskell: Stripe API for Haskellというパッケージがあるのですが, これが新しいstackageのltsに登場しないので自分のソフトウェアのltsをアップデート出来なくて困っています.

extra-depsに指定すれば良いのかなと思って色々やってみましたが, パッケージの依存関係がなんかダメでダメでした.

OSSdmjio/stripe: Stripe APIなので, 利用者が修正出来るはずなので, 修正をやっていこうと思います.

元ソースだとNixOSに依存しているのかstack.yamlが存在せずにstack-head.yamlみたいなファイルがたくさんあって謎です. これだとビルドがまず出来ない…

stackageの方だとaesonのバージョンに制限をかけていてビルドが出来ないらしいことがわかっているのでそこだけ直すのが良いんでしょうが, stackがセットアップされてないとテストすることも難しい…

かと言ってstackのビルドオプション提供してないのはリポジトリ提供主の意志だろうし追加したpull requestを送って良いのかもよくわからない…

もっと英語力とコミュニケーション能力があれば根回しもできたんでしょうけど.

とりあえず送ってみて対応して欲しいという需要があることを示してみますか.

試しにstack.yamlを最新版で追加してビルドしてみたらライブラリのバージョン上限を設定しているせいでビルドができなくなっていました. 個人的にはstackを使うならライブラリのバージョン上限指定は不要だと思っているのですが, nixでのビルドを壊してはいけないので上限設定を尊重しようと思います.

とりあえずささっと直せるものだったのでpull requestを作ってみましたがどうも何か間違っているような気がします. add stack build by ncaq · Pull Request #78 · dmjio/stripe 英語力とコミュ力と技術力が欲しい…

と思ってtravisの設定を見たらさっそくコケている. コミュ力より技術力が問題でしたか. nixのビルドでコケているようですが, nixのことは何もわからないので何もわからない… と思ってググったら割と簡単にわかった. ghc801は環境から削除されているみたいですね, そんな簡単に削除されてしまうものなのか…

nixのコンパイラ削除だけが原因だと思ってたらそうでもないらしい. nix環境のcabalでのビルドがnats-1.1.1を発見できなくて死んでいる. なぜ? nixにもnats-1.1.1はあるようなのに… nixの存在意義やnixの仕組みを理解していないからなのか, 何故なのかよくわからない.

travisの結果が出揃ってきて, 本当に正答しないといけないenv: GHCVER=ghc802の場合は正解しているのでまあとりあえずは良いかという気持ちになりました. GHCVER=ghc801は存在しないので消しておきました. 1つのpull requestでテスト修正作業を行うのは悪行ですが, travis CIを通らないpull requestを出すのとどっちが悪いのかは謎です. 私はテスト通ってないものを出すほうが悪いと思ったので修正しました.

stripeのSMS2段階認証が出来ないのでサポートに連絡しました

travis CIでのテストがnixを前提にしているようなので, とりあえず手元でstack testを実行してみようと自前のstripeキーで実行してみたら電話番号を認証しろと言われたのでSMS認証しようとしてみたら

Sorry, there was a problem. We weren't able to reach that number. Please try another.

と言われて認証が出来なかった. iijmioの音声通話をサポートしていないSMSオンリーの番号だから出来ないのかな… IP電話の方も入力してみましたがうまくいかない.

ダッシュボードの方からSMS認証をしてみようとしましたがうまく行かず…

もしかしたらgoogleの2段階認証有効にしたらSMSの代わりにならないかなと思って認証してみたのですが

You must verify a phone number on your Stripe account before you can send raw credit card numbers to the Stripe API

からエラーメッセージが変わらず… じゃあgoogle2段階認証は何のためにあるんだろうか…

SMS代行サービスを使えばSMS認証は出来るんでしょうが, 2段階認証用のセキュリティのためにどこぞの知らない業者にワンタイムパスワードを渡してしまうのは完全に本末転倒に感じて実行できない…

色々カスタマイズしているfirefoxで実行しているのが悪いのかなと思ってchromiumに切り替えて実行してみましたが, やはりうまくいかない.

stripeのprofileのmobile numberの方には問題なくIP電話の番号を追加できているのですが, 何故…

コンソールを見たりしてみましたが自分ではわからないことなので, stripeのサポートにコンタクトを取ってみることにしました. ガバガバ英語でも書くのが疲れました. Stripeがこの番号に対応してないとかならそういった連絡が帰ってくることでしょう. 他の解決可能な問題だったらラッキーですね.

stack solverに任せずに手で外部依存ライブラリを書いたらltsをアップデート出来ました

やっていくうちに｢なんでこれstack solverで外部パッケージに指定して動かないんだろう…｣という気持ちになってきました. 前試した時とは状況が異なるのかもしれないと思ってもういちどアップデートを試してみます. そしたらやっぱり失敗, io-streamsの正しいバージョンが取れないみたいですね. やっぱり私のpull requestは必要だったみたいです.

でもこの制限ならio-streams-1.3.6.1を指定すれば動くんじゃないか…? と思って指定してみたらあっさりビルドできました. stack solverの探索ってそんなに深く行わないんですね.

ソースコードを読むことで, 期せずしてライブラリのpull requestによる修正ではないアップデートが出来てしまいました…

lts-9.5にアップデートするコミットしてpushした途端lts-9.6が出たんですが, ジンクスか何か?

goofysからS3 APIを利用する構成に切り替えたけどgoofysのままのほうが良かったのかもしれません

このwebアプリケーションの初期段階ではgoofysを使って, ファイルをユーザに送信するときはsendFileを使ってファイルシステム上のファイルを送信していました.

ここで, 大容量ファイルを配信するときに, webアプリケーションサーバを経由してファイルを配信するのは効率が悪いのではないかと思い, S3 APIを使ってS3のURLにリダイレクトさせる方式に変更しました.

しかし, goofysから移行することで, いろんな問題が発生したので, goofysから移行したのは失敗だったかもしれません.

• テスト時にローカルのディレクトリを使えずにS3を使うので非常にテストが遅くなる
• アクセスがあるたびにpre-signed URLを使ってファイルのパブリックURLを作成しているため, 2回めにアクセスする時キャッシュが効かなくなる
• アップロードするときにMulti Part APIを使うがこれがgoofysでアップロードするのと速度が大差ない
• ファイルサイズへのアクセスが遅い, goofysを使っていればfuseでキャッシュされる?

基本的にgoofysを使って, 大容量ファイルの配信のみS3のURLに直接リダイレクトさせるという方針の方が良かったかもしれません.

しかし, webアプリケーションサーバを複数設置するような構成だとgoofysは使えるんだろうか, 謎です.

そんな深刻な問題でも無いけれど…

SetはFunctorのinstanceにならなかった

unordered-containers: Efficient hashing-based container typesのHashMapはFunctorのインスタンスなのに, HashSetはそうではないということで少し悩みました. MapとSetもそうなっているみたいですね.

でもHashSetモジュールにメソッドではないmapがあるから原理的に定義できそうな気がします.

とりあえずpull request出す前に孤立インスタンスで良いから実装できるか見てみますか.

と思って実装してみようと思いましたが実装できませんでした.

もう一度調べ直したところ, SetはFunctorではない - xuwei-k's blog という記事が出てきました.

なるほど_{Setは一般的にFunctorじゃないのか} issue建てなくてちょっと調べて良かった. ならmapって名前はやめて他の名前の方が混乱しないかもしれませんね.

最終的にNo instance for (Hashable (Key a))と言われてしまいました… まあKeyは数値か文字列なので, HashSetとSetの速度は変わらないでしょうが.

と思って適当に作業していたら今度はCould not deduce (Ord S3.ObjectInfo)と言われました… リストのままで問題はなさそうですが, S3.ObjectInfoはShowしかderivingしてないのか…

結局色々考えたけど最終的な設計ではSetを1箇所にちょっと使うだけで, Functorにinstanceじゃない問題は全く関係しませんでした.

yesod-develが止まらなくなった

アップデートの影響か, yesod develが自前のwebpackの呼び出しでファイル変更を感知してリビルドをかけて, stackとwebpackのビルドループに入るようになってしまいました.

yesod develによるwebpack --watchの起動を諦めて, tsxをビルドするときは手でやる方に切り替えるべきでしょうか.

今日はもう作業をやめるので, 今度解決しようと思います.