見出し画像

プログラム多言語の相互乗り入れはカオス。路線変更でPythonにほぼ統一化

大和 司

今日の夕方ぐらいにZbrushプラグイン開発の半分が終了。往復でワンセットの処理のうち往路をexe化してZscriptから呼び出し。つまりはZbrush上のボタンワンクリックで所定の機能が発動して終了することを確認した。

普段ならこのまま後半戦に突入するのだが今回は色々と分けが違う。なので半日ほどかけて振り返りつつまとめてみることにした。

また夜中に😭生活リズムが夜中にずれ込んでいるこれはまずい。

（約 3,600文字の記事です。）



プログラミング多言語相互乗り入れのデメリット

今回はPythonを中心としてGUI操作周りをAutoHotkey v2で、ZbrushとのやりとりをZscriptで実装した。3言語も使っている。そして実際に片道分の機能をexe化して実装完了した。そして見えてきたものがあった。

結論を言えば「デメリットの方が多かった」のだ。罠も多かった。かなり凹んだ。順調に進んだ工程と、メチャクチャ泥沼の工程がハッキリと分かれた。

各モジュール開発時はテンポよく

GUI関連ならばAutoHotkeyでサクサク作る。ドキュメントも充実しているので小気味よく進んだ。Pythonを使ったデータ処理エンジンも同様。どちらもChatGPTの助けも借りて、割とアイディアをポンポンとコーディングできた気がする。

結合で泣くことになった

そして本題。結合テストからがカオス。具体的には、

  1. 言語間の変数のやりとりが一手間かかる。そりゃ言語が違うからね。

  2. PythonとAutoHotkeyでバックスラッシュの取り扱いが異なる（エスケープ文字の有無）

  3. 各言語で「フォルダパスやファイルパス取得」の関数や記法が異なる（当たり前）

  4. モジュール開発中のファイルパスと結合環境でのファイルパスの違い

  5. PyCharm上でのpyファイル時のファイルパスとexe後の本番環境配置状態でのファイルパスの違い

  6. 同様にフォルダパスも変わる

  7. exe化前後でも実体ファイルから見たフォルダパスが変わる

  8. PythonやAutoHotkeyは相対パスが使えるがZscriptは諸事情によりまさかの絶対パス縛りだった

これだけ悪条件が揃うと、泥沼😭結局この7項目を全部クリアするのに3日かかった。今は動いているが、ファイルパスをPythonとAutoHotkeyでやりとりする実装変更が割と既にスパゲッティーになりつつある。

一方でPythonやahkのみで組んだエンジン周りはほぼ完璧で何も問題なし。トラブルの種は一貫してファイルパス、フォルダパス、そのPythonとahkとの受け渡しで発生していた。py開発中、exe化、本番パス移動時で次々とランタイムエラーである。そしてラスボスは、ZscriptでのZbrushへの実装、諸事情によりまさかの相対パスが使えない罠。

Zbrushよ、Zscriptよ、またお前なのか。

ahk.exeに引数渡しできたら楽だったのに

Pyarmorでの難読化のためにahkは直接exeへahkソースを渡していない。なので引数私が使えないという事情があった。だからややこしい。ソースファイルに文字列として追加する形で新変数を追加するという頭の悪い実装に。それしか手がない。

そうせざるを得ない事情として、ソースコードの難読化がある。PyarmorはPythonのソースコードを難読化してexe化できる。そのためにはahkファイルとして独立して存在させるのではなくて、あくまでもpyファイルにする必要があった。

だが待てよ？本当にPyarmorはpyファイルしか難読化できないのかな？テキストファイルだったら実は難読化できたりしないかな？調べてみた。



2時間後、

何の成果も得られませんでした😭


やっぱりPyarmorはpyファイルしか難読化できないっぽい。オワタ。振り出しに戻る。


Python＋ahk？ Pythonから呼び出すahk？

Pythonでahkを利用する方法は2種類ある。

  1. ahkソースコードを丸ごとテキストとして変数に読み込んで実行（変数をahkに渡して実行するイメージ）

  2. PyPi ahkラッパーで1行ずつラッピングしてPython化し、あくまでもPythonソースコードの一部として実行

今の実装は前者。作業の固まりがahkのみで完結する「予定」だったので。だが実際にはファイルパス＋ファイル名のやりとりが発生。つまりPythonからahkに変数で情報を渡す必要がでてきた。だが引数渡しは使えない。そして泥沼からアイディアをひねり出して実装完了。だが美しくないしメンテナンス性も悪い。今回はしのいでも次は厳しい。

2にすれば基本的にPythonなのでごく普通にコーディングすればいい。だが手間としてはahkとして完成させたソースコードをPython流にラッピングする二度手間になる。これが嫌で最初は1を採用した。だがどうやら無理がある。

そしてマインドマップで色々検討した結果、やはりというか、2を採用し直すことにした。というのもメリットが幾つかあるからだ。

  1. ラッピングすれば1関数単位で「いつでも」Pythonで使えるので、将来的に自前の資源としてコードを使い回しできる

  2. PyPi ahkは今はv1をメインでカバーしてv2は一部のみカバー中だが、1つのソースコード内で両者を簡単に使い分けできた。なのでv2未対応のラッピング関数もv1でカバーできた

  3. Pythonでラッピングしてしまえば実はahk v1とv2の文法・記法の違いはなくなる（ラッパーのいいところ）

  4. 短時間のうちにahkとPythonのコーディング作業が入り交じらないので混乱しにくい（基本的にahkで動作確認できてからPythonラッピング作業）

  5. 変数の受け渡しの作法の違いが解消される（Python流で統一できる）

  6. PyCharmのデバッガが使える【割と重要】

  7. フルでPythonなのでPyarmorで問題なし

  8. フルでPythonなのでPyCharmで完成まで持って行ける（開発環境の1本化）

幾つかどころじゃなくてたくさんあったわ😅


【まとめ】Pythonに統一（ラッピング）

こうやって冷静に考えた結果、Python＋ahkの併走よりも、

  1. ahkが必要なモジュールをVS CodeでAutoHotkey v2でIDE環境の力を利用してサクッと実装し

  2. バグ取り終了したらPyCharmに移植してPythonラッピング作業

  3. Python上でバグ取りが終わったらPyCharm上で結合テスト

このステップを踏んだ方が一方通行でスッキリ実装できることが判明。こうすればフォルダパスやファイルパスはすべてPython流儀で1本化できる。PythonはPythonで.py時とexe化後で「今のパスの値」が変わることが分かっているので、その対策ももう関数化して今回実装した。こういう過去の資源を未来に生かせる点でもPythonで統一化した方が旨味が多い。

なので今回の学びとしてはahkを利用する際にどの程度までブロック化してahkで処理させるか、どこから/どこでPythonとバトンタッチするかの境界線は、実はクッキリハッキリさせなくてもいいことが分かった。最終的にPythonラッピングされればPythonコードになってしまうわけで。なので仮仕様でahkとしてVS Code上で動作検証してしまえばそれでOKということに。

結局はラッピングによってahkをPythonに寄せることになった。GUIインターフェース周りをTkinterの代わりにahkラッパーを使う。コード行数はどちらも大差ないが、AutoHotkeyの方が「より普通のWindows GUI」として機能するw ……Tkinterは、ちょっと勘弁して欲しい。


とりあえず今日までで、

  1. ZbrushのボタンをZscriptで実装完了

  2. 本番環境でもフォルダパスやファイルパスの指定が正常

  3. Zscriptから「開発中の.py」と「完成後のexe」のどちらを呼び出しても正常に動作することを確認できた【最難関】

  4. 予定通りのデータ処理完了

  5. 全体の50％が実装完了

こんな感じ。1～3が実現できたことで今後の見通しが立った。あとは4がボタンごとに異なるだけなので、新たな技術的課題はほぼ無し。ウィンドウアプリはそんなもんだ。1ボタン1機能の組み合わせに過ぎない。今回、その1パターンを実現できたことが非常に大きい。

だからこそ今回の振り返りでこのパターンの流れを点検しておく必要がある。うまく回る仕組みを作ってからガンガン回した方が効率的だ。

とりあえず今日はおしまい。また夜中～😭


今回の創作活動は約1時間30分（累積 約3,861時間）
（1,109回目のnote更新）



読んでくれてありがとう。気長にマイペースに書いてます。この出会いに感謝😊