Sho Kusano

提供元データの内容をそのまま使っているので正式名称ではない状態です。 信組を一括置換するなどして解決できそうなのですが、そのデータ加工を今実施するとデータの一貫性が大きく損なわれるので、検討項目とさせてください。

I don't know the source of the SWIFT code and the corresponding data of the bank. If you know that, let me know.

woothee-php のように、 DataSet.php を submodule から生成する方式の方が手っ取り早そうに見えるんですが、あえて source-data を composer に登録する意図はなんなんでしょう？ https://github.com/woothee/woothee-php

> woothee の更新に合わせて woothee-php も更新が必要となってしまう為 現在 zengin-rb も zengin-js もそうやって運用しているので、悪いとは思っていません(source-data の変更に追従して両方のバージョンがあがる)。 依存が増えることと、 source-data という独立したリポジトリを PHP 用に改変することの2点を超えるほどの利益をイマイチ見いだせていないです。 更新作業そのものは CI 上で自動化している(し、 PHP 版も同様に自動化する)ので、メンテナンスコストという意味では問題ないかなとも思っています。 ちょっと composer の仕組みがわかってなくて理解が甘い気がしているので、少し勉強してきます。

@fagai 以前の回答と同様で、 woothee-php と同様にデータセットの PHP を生成する方式を実装しない理由がなく、また source-data は『特定の言語のための実装』を入れるべきでないと強く考えているため、このリポジトリに composer.json を追加することはありません。 ccomposer.json の更新で他言語実装のリリースが走ることは許容できないためです。

Gomfile.lock を生成しているだけで、何かに利用されているように見えないけれど、これは何を解決したいんでしょう？

`go get` および `go install` は自動的に処理系のバージョン名の tag を探して適用する仕組みになっています(`go1` など)。 ただ、 tag は変わりうるものなので `lock` があることは重要だと感じていますが、生成するだけで利用されないのでは問題なので `lock` も考慮してインストールするようにならないといけないですね。

Hi, @janckerchen There are 2 ways to solve your problem: #### First, Change the import path to be relative. ``` go import "models/user" import "./models/user" ``` This solves your problem...