HSPTV!掲示板

HSP向けパッケージマネージャ: hpkを作りたいと考えています(Python: pip, Node.js: npmに該当するもの)。

想定している仕様は以下です

- クロスプラットフォーム: HSP3DishやOpenHSP(LInux)に対応
- 上記を目標にするため、初期バージョンはひとまず.hspや.asのみを含む(.dllなどを含まない)パッケージを配布できることを目指す
- pypi.orgやwww.npmjs.comのような中央集権的パッケージリポジトリは用意せず、GoのようにGitHub等で各々が公開し、利用者はそのリンクを指定することで利用できるようにする
- CLIはGoで制作しているが、余力があればGUI版(操作は内部でCLIを呼び出して行う)をHSPで制作したい

パッケージマネージャを作るに当たり、以下の依存関係管理方法が考えられそうですが、それに当たって私がわかっていない点があるため、有識者の皆様にご教授願いたいです 🙇

## グローバル依存関係

pipのように、一度ダウンロードするとどのプロジェクトでも呼び出せるようにする方式です。

この方式を取るに当たって私がわかっていない点は以下です。

- Win版HSPでは`hsp36/common`で.asを管理しているが、これ以外で管理しているディレクトリがあるか/任意に指定する方法があるか
- というのも、あまり`hsp36/common`の書き換えをhpk側でしたくない…最悪する場合は元あるファイルを書き換えないような仕組みを考えないといけない
- OpenHSP(Linux)やHSP3Dishではどこで共通の.asを管理しているのか

## ローカル依存関係

npmのように、プロジェクト内にフォルダ(`node_modules`など)を作成して管理する方式です。

この方式を取るに当たって私がわかっていない点は以下です。

- この方式を取る場合、プロジェクト管理フォルダ(以降`hpk_packages`と呼称)をコンパイラetcに指定する方法があるのか？
- ない場合、PHPのComposerのようにautoload.asなどを動的に構築して読み込む方法が適切だろうか？
- その場合、そのプロジェクトは`#include “hpk_pakcages/autoload.as”`が必要になり、hpkが必須になりそうだが許容されるか？

- 上記の疑問点に関する解答/それが示されているURL
- グローバル/ローカル依存関係のどちらが適しているかのご意見
- 現状制作しているhpkに関する質問
- すでに存在する似たプロジェクトの存在
- その他疑問点やアドバイス

など、どのような観点でのご意見/ご質問等も大歓迎です！よろしくお願いいたします 🙇

頑張ってください！ 応援しています！！

>## グローバル依存関係
>- Win版HSPでは`hsp36/common`で.asを管理しているが、これ以外で管理しているディレクトリがあるか/任意に指定する方法があるか
>## ローカル依存関係
>- この方式を取る場合、プロジェクト管理フォルダ(以降`hpk_packages`と呼称)をコンパイラetcに指定する方法があるのか？
読み込みフォルダはソースファイルのディレクトリ(ローカル)とcommmonフォルダのみだと思います。
https://www.onionsoft.net/hsp/v37/doclib/hspprog.htm#COMMON_DIR


>- グローバル/ローカル依存関係のどちらが適しているかのご意見
私も
>あまり`hsp36/common`の書き換えをhpk側でしたくない
という想いはありますが、ローカルだとF1キーヘルプが使えないのが歯痒いなと感じます。

モジュールを利用するときキーワードにカーソル当ててF1キーひとつでコマンドの詳細を確認できるのは非常に強力です。（モジュール作者さんがヘルプを作ってくださっていたらですが...）
このF1キーヘルプは hsp36/hsphelp や hsp36/doclib に.hsファイルがあるか、commonフォルダのモジュールファイル内に直接hs形式のテキストが含まれている必要があります。
https://www.onionsoft.net/hsp/v35/doclib/HSP%20Document%20Library/hdl_usage.htm
(common内モジュールのhs形式テキスト例: https://github.com/MIZUSHIKI/HSP-Module/blob/master/mod_TimerRepeat.hsp )

私も現状答えは出ていませんが、パッケージマネージャによってしっかり管理されるのであれば、どちらかと言えば グローバル依存 の方を推したいかなと思います。

ただ グローバル依存 の場合の懸念点ですが、将来的に.dllなどを含むパッケージに対応しようとしたときに .dll は hsp36フォルダ に放り込まれることが予想されます。
開発者がいざソフトウェアを頒布しようとしたときに関連する.dllが分からず『#Error 38 -->内部エラーが発生しました(38)』と出て解決できない(初心者は特に) なんてことも想像できます。
何かうまい解決策や導線を考えておく必要があるかもしれません。。。


また、もし ローカル依存 を進められる場合ですが、

>## ローカル依存関係
>PHPのComposerのようにautoload.asなどを動的に構築して読み込む方法が適切だろうか？
>- その場合、そのプロジェクトは`#include “hpk_pakcages/autoload.as”`が必要になり、hpkが必須になりそうだが許容されるか？
これは別に許容して良いのではないでしょうか。
グローバル依存 が採用された場合でも、パッケージが未インストールだったら パッケージマネージャ: hpk は必要になりそうですし。
プロジェクトが共有される場合は、「既に必要なパッケージをダウンロード + autoload.asの中で全て#includeが書かれた後のプロジェクト」が共有されそうな気がします(?)


>- クロスプラットフォーム: HSP3DishやOpenHSP(LInux)
私はこれらに関して明るくないため、Linuxなどの環境でどうなるかは分かりません。
なので上記に書いた内容はWindowsの環境に限定した内容とお考え下さい。


>- すでに存在する似たプロジェクトの存在
今までHSP3向けパッケージマネージャを上手く稼働できているのは見たことありません。
ただ、過去に議論されたスレッドを見つけました。
https://hsp.tv/play/pforum.php?mode=pastwch&num=41744

上記スレッドでは途中で方向性が怪しくなっていたりして、やはり頓挫しやすい物ではあると思いますが、
興味を持っている人、期待している人、欲しいという声も多くあるみたいなので、ぜひ頑張ってみて欲しいです！

>101104

ご丁寧にありがとうございます！！

>読み込みフォルダはソースファイルのディレクトリ(ローカル)とcommmonフォルダのみだと思います。
>https://www.onionsoft.net/hsp/v37/doclib/hspprog.htm#COMMON_DIR
ありがとうございます！やはりそのどちらかで頑張るしかなさそうですね...

>ローカルだとF1キーヘルプが使えないのが歯痒いなと感じます。
なるほど、たしかにヘルプに関しては想定していませんでした。

>私も現状答えは出ていませんが、パッケージマネージャによってしっかり管理されるのであれば、どちらかと言えば グローバル依存 の方を推したいかなと思います。
そうですね、総合的に考えると自分もグローバルに管理したほうがよさそうな気がします(ヘルプの件もありますし)。

>ただ グローバル依存 の場合の懸念点ですが、将来的に.dllなどを含むパッケージに対応しようとしたときに .dll は hsp36フォルダ に放り込まれることが予想されます。
>開発者がいざソフトウェアを頒布しようとしたときに関連する.dllが分からず『#Error 38 -->内部エラーが発生しました(38)』と出て解決できない(初心者は特に) なんてことも想像できます。
>何かうまい解決策や導線を考えておく必要があるかもしれません。。。
そうですねー、自分としてはnpmのようにインストール前/後に実行されるスクリプトを指定する機能( https://docs.npmjs.com/cli/v10/using-npm/scripts#life-cycle-scripts )(セットアップ用途)や、環境の違い(HSP, OpenHSP, HSP3Dish)で処理やincludeされるファイルを切り替える機能等を検討しています。
少なくともこれで広いOS向けのパッケージを提供できるようになるんじゃないかな...と考えています。
ただ、そもそも.dllが必要なパッケージは結局上記では解決してないので、私自身もMIZUSHIKI様のおっしゃるとおり上手い仕組みを考える必要があると思います。
また、これは余談なのですが、Linuxでは.dllやuselibが使えない(という認識です)ので、.dllに依存しているパッケージはポータビリティ(Win以外での実行可能性)がほぼなくなってしまうんですよね...
いくらOSで切り替えられるからと言って、Linux等で同等の機能を持たせるための仕組みがないとなると、ここらへんも課題になってくるのかなあ...と思っています。

>>## ローカル依存関係
>>PHPのComposerのようにautoload.asなどを動的に構築して読み込む方法が適切だろうか？
>>- その場合、そのプロジェクトは`#include “hpk_pakcages/autoload.as”`が必要になり、hpkが必須になりそうだが許容されるか？
>これは別に許容して良いのではないでしょうか。
>グローバル依存 が採用された場合でも、パッケージが未インストールだったら パッケージマネージャ: hpk は必要になりそうですし。
>プロジェクトが共有される場合は、「既に必要なパッケージをダウンロード + autoload.asの中で全て#includeが書かれた後のプロジェクト」が共有されそうな気がします(?)
ありがとうございます！読み込まれるディレクトリが指定できない以上、ローカルの仕組みにするならこれが一番妥当そうですよね。

>私はこれらに関して明るくないため、Linuxなどの環境でどうなるかは分かりません。
>なので上記に書いた内容はWindowsの環境に限定した内容とお考え下さい。
ありがとうございます！読み込みに関しまして、Winの事情がだいぶクリアになりましたので、これを参考に自前のLinux環境で検証してみたいと思います。

>今までHSP3向けパッケージマネージャを上手く稼働できているのは見たことありません。
>ただ、過去に議論されたスレッドを見つけました。
>https://hsp.tv/play/pforum.php?mode=pastwch&num=41744
>
>上記スレッドでは途中で方向性が怪しくなっていたりして、やはり頓挫しやすい物ではあると思いますが、
>興味を持っている人、期待している人、欲しいという声も多くあるみたいなので、ぜひ頑張ってみて欲しいです！
ありがとうございます😭 上記のスレを軽く見ましたが、あちらではどうやら中央集権的リポジトリも構築しようとしていたみたいですね(自分は今後それを責任持って永続的に運用する自身がなかったので諦めてしまいましたが^^;)。
応援もありがとうございます😭 上記で頂いたものを参考に、方向性を決めていこうと思います！

>BonyChops さん

HSP向けパッケージマネージャについてのご提案ありがとうございます。
私の方でもHSP3本体やプラグイン等を管理するシステムの必要性を感じていて、
次のβ版となるHSP3.7β8ではテスト版としてHSP3アップデーター(hsp3upd.exe)を
導入したいと考えています。
これは、インストールされたHSP3のバージョンを任意に選択できるほか、
マルチプラットフォームサポートの機能などを個別にインストールする形を取ることで
配布サイズを少なくするという目的もあります。
hsp3upd.exeは、以下のSVNリポジトリから取得することができます。
https://dev.onionsoft.net/trac/openhsp/browser/trunk/package/win32

実際のパッケージデータは、以下のSVNリポジトリが参照されています
https://dev.onionsoft.net/trac/hsp3update/browser

ゆくゆくは、このシステムの延長で、ユーザー開発によるプラグインやモジュール等を
読み込めるようにして、好きなものを任意に導入することができればと思っていました。
(pipなどと同様の仕組みです)

BonyChopsさんがパッケージマネージャを製作されるのはもちろん歓迎で、
このシステムを使って欲しいということではありません。
HSP3の追加プラグインやモジュール、ツール類や素材は多岐に渡っていて
できるだけ、多くの製作者が手軽に参加できる形で共通の基盤を作っていけることを願っています。

こちらで現在作成しているものは、win32(Windows x86)をターゲットにしていますが、
x64やlinuxなど異なるシステムでも同様に動作する仕組みができることが望ましいと考えています。
パッケージやプラグインの導入を手軽にできるよう、皆さんの意見をもとにある程度方向が決められたら嬉しいです。
HSP3のシステム側への要望や対応についても、ご提案頂ければ助かります。

あと、HSPが参照する commonフォルダは、すべてのスクリプトが参照するシステムフォルダで
パッケージマネージャーがこの中にファイルを追加すること自体は問題ないかと思います。
(Linux版やHSP3Dishも含めてこの仕組みは共通です)
ただ、既存のファイル(hsp3dish.asなど)を書き換える場合は、元に戻せるようにする必要があるかと思います。
引き続きよろしくお願いいたします。

>101116

おにたま様！まさかご本人に見ていただけるとは…いつもHSPの開発お疲れさまです🙇‍♂

>私の方でもHSP3本体やプラグイン等を管理するシステムの必要性を感じていて、
>次のβ版となるHSP3.7β8ではテスト版としてHSP3アップデーター(hsp3upd.exe)を
>導入したいと考えています。
>これは、インストールされたHSP3のバージョンを任意に選択できるほか、
>マルチプラットフォームサポートの機能などを個別にインストールする形を取ることで
>配布サイズを少なくするという目的もあります。

>ゆくゆくは、このシステムの延長で、ユーザー開発によるプラグインやモジュール等を
>読み込めるようにして、好きなものを任意に導入することができればと思っていました。
>(pipなどと同様の仕組みです)
そうだったんですね！先程リポジトリから落として試してみました。
私が開発しているのは、hsp3upd.exeで言えばまさに”追加パッケージURL”の部分にあたるのかなと思います。
公式の方でこのような仕組みが準備されている場合、私としてはできるだけその機能と連携を取りたいと考えております。
私の認識違いであれば大変恐縮なのですが、hsp3upd.exeはHSP環境ごとのパッケージを管理するツールと認識しております。
hpkはプロジェクト単位で依存関係を管理する(最終的に必要なパッケージがHSP環境に反映される)ものを想定していますので、hpkを使用するユーザーはhpkでインストール→最終的にhsp3updにも反映される、のような仕組みで連携が取れるのではないかな…と考えています。
無論、hpkはあくまでもサードパーティのツールであり、上記はhpkの仕様として考えられるというだけで、公式側で連携に協力していただく必要はございません！
元のシステムを壊さないよう、HSPで使うことができるツールとして開発したいと考えております🙇‍♂

>こちらで現在作成しているものは、win32(Windows x86)をターゲットにしていますが、
>x64やlinuxなど異なるシステムでも同様に動作する仕組みができることが望ましいと考えています。
>パッケージやプラグインの導入を手軽にできるよう、皆さんの意見をもとにある程度方向が決められたら嬉しいです。
>HSP3のシステム側への要望や対応についても、ご提案頂ければ助かります。
ありがとうございます！これは若干別件なのですが、Linuxでもpipeexecやuselib(Linuxだと.soなど)が使えるととても拡張性が広がると思います。
現状Linuxで外部プロセスやライブラリを呼び出すのが難しい以上、異なるシステムで動作するパッケージを構築するのが難しいと考えています。

>あと、HSPが参照する commonフォルダは、すべてのスクリプトが参照するシステムフォルダで
>パッケージマネージャーがこの中にファイルを追加すること自体は問題ないかと思います。
>(Linux版やHSP3Dishも含めてこの仕組みは共通です)
>ただ、既存のファイル(hsp3dish.asなど)を書き換える場合は、元に戻せるようにする必要があるかと思います。
ありがとうございます！そうですね、現状はシステム側でインストールされたものを書き換えないような仕組みを考えたいと思っています。

>BonyChopsさんがパッケージマネージャを製作されるのはもちろん歓迎で、
>このシステムを使って欲しいということではありません。
>HSP3の追加プラグインやモジュール、ツール類や素材は多岐に渡っていて
>できるだけ、多くの製作者が手軽に参加できる形で共通の基盤を作っていけることを願っています。
ありがとうございます！私も同感です。私が人生で初めて触ったプログラミング言語がHSPで、現在のような活動ができるようになったのもこの言語が起点となっていると考えています。
そんなHSPのコミュニティを盛り上げることに自分もぜひ加担したい思い始めようと思いました。
HSPを作ってくださったおにたま様はじめ関係者の方には改めて御礼申し上げます。
また、このプロジェクトにOKを出してくださりありがとうございます。
サードパーティのツールとして、HSPの環境やおにたま様にご迷惑がかからないよう、ツールを作っていければと思います。

>引き続きよろしくお願いいたします。
こちらこそ、よろしくお願いいたします。

方向性に関しましてある程度見えてきましたので、いったんスレを解決に設定させていただきます！
スレは定期的に確認しますので、引き続き本件に関してご意見/ご質問がある方はよろしくお願いします🙇‍♂

>BonyChops さん

返信ありがとうございます。
hpkの概要について承知致しました。
HSP3にはプロジェクトという仕組みが希薄なので、ローカルで管理するようなうまい方法をご提案頂ければ、こちらでも対応していきたいと思います。

>Linuxでもpipeexecやuselib(Linuxだと.soなど)が使えると
>とても拡張性が広がると思います。

ご提案ありがとうございます。
確かにプロセスの管理などシステム寄りの制御ができるとより便利になると思います。

>サードパーティのツールとして、HSPの環境やおにたま様にご迷惑がかからないよう、
>ツールを作っていければと思います。

多くの人にとって有用なツールや提案などあれば、これからもよろしくお願い致します。
限られた時間を割いて頂き感謝します。