Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

requirements系の管理をCross Platform対応が必要か? #220

Closed
qwerty2501 opened this issue Dec 5, 2021 · 1 comment · Fixed by #535
Closed

requirements系の管理をCross Platform対応が必要か? #220

qwerty2501 opened this issue Dec 5, 2021 · 1 comment · Fixed by #535
Labels
優先度:低 (運用中止)

Comments

@qwerty2501
Copy link
Contributor

内容

現状 pip-compile を使用して requirements.txt系の出力を行うと、出力結果が実行したOS環境によって異なってしまう問題がある
Windowsで必要とされてるものがUbuntuで出力したものだと削除されてしまうのでこのままの状態で違うOS間で開発を進めてしまうと、開発環境構築に問題が生じる可能性がある。

対応案

A: requirements.txt系をgit管理対象からはずす

git管理対象からはずしてrequirements.txt系は.gitignoreに登録する。requirements.txt系の生成は各開発者がインストールする際に自分で行う

Pros 良くなる点

  • 各々で必要なrequirements.txtが生成されるためOS環境の差異による問題がおそらく解決できる

Cons 悪くなる点

  • 開発環境構築の際に実行するコマンド量が増える(インストールスクリプトのようなものを作るべき?)
  • flaskのような大きなプロジェクトではrequirements.txt系はgitの管理対象にしているのでこの案はアンチパターンかもしれない

B: requirements.txt系をOSごとに生成する

出力するrequirements.txt系のファイルをOSごとに分ける

Pros 良くなる点

  • 各々で必要なrequirements.txtが生成されるためOS環境の差異による問題が解決できる

Cons 悪くなる点

  • 開発環境構築の際に手順が分岐することになり分かりづらくなる
  • pip-compileの出力内容が環境に依存するため新しくライブラリを追加する際に実装者単体でrequirements.txtのメンテを行うことが難しくなる
  • おそらくOSごとにメンテナーが必要になるので開発に対する負荷が増える

C: 開発環境をWindowsのみに固定し、ほか環境からの修正は受け付けない

現状Windowsでの開発者が大半を占めるので割と現実的な案であるが、Mac OS版リリースをしようとしているようなので、今後複数環境のメンテナンスを行わなければならないということを考えると開発の持続性を維持できなくなるかも?

Pros 良くなる点

  • 実質現状維持であるため対応することがない

Cons 悪くなる点

  • 知らずにWindows環境からPRを出すことは考えられるので同様の問題が発生する可能性は消せない
  • Windows以外の開発者を呼び込むことはできない

その他

参考までにPip-tools for Cross-OS developmentというタイトルのブログを見つけたので貼っときます。
ここの Write the requirements.inという項に対して

This is the only thing you need to include in your versioning.

と書いてあるのでこのブログで書いてあることが正しいのであればgitの管理対象に含めるのは requirements.inのみでよく、生成したrequirements.txtはgit管理対象から外して良さそうです。
A案が有力そう?

@Hiroshiba
Copy link
Member

issueありがとうございます!

個人的には、一旦C案で行きつつ、良い解決策が見つかるまで凌ぐことになるかなと思っています。

A案はOS依存を取り除ける良い案なのですが、そもそも.inと.txtを作った経緯が、lockの役割を担わせるためなんですよね。
lockできなくなっちゃうので、.txtをgit管理から外すのは避けたいところです。

B案が現状思いつく最良の解決策なのかなと思います。
が、まあいまのところC案で行っても大丈夫なので、優先度を低くしつつ、より良い解決策が思いつくか、どうしようもなくなるタイミング、もしくは率先的に解決できる方が現れるまで放置で良いのかなと考えています。

PS.
pipenvとかも同じ問題抱えてるはずで、そちらに良い解決があればいいんですけどね・・・

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
優先度:低 (運用中止)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants