Order of loading ARX modules

[gswifort]

Issue discussed in #1 and #86.

In what order are ARX modules (and clones) loaded? From my observations, if we have modules installed globally (%localappdata%\Programs\...), PyRx25.0.arx is always loaded from the global directory. If there is no global installation, the module located in the same directory as RxLoader25.0.arx is taken - is this the intended effect? The pyrx_onload.py file is loaded from the same directory as PyRx25.0.arx.

K:\Programy\demos\__temp_pyrx_install\venv\Lib\site-packages\pyrx\PyRxBin\RxLoaderZ25.0.zrx loaded successfully.
Command: 
PyRxLoader::getPythonVenvPath K:\Programy\demos\__temp_pyrx_install\venv
PyRxLoader::thisModulePath K:\Programy\demos\__temp_pyrx_install\venv\Lib\site-packages\pyrx\PyRxBin\
PyRxLoader::getInstallPath C:\Users\gswi\AppData\Local\Programs\PyRx
PyRxLoader::getIniPath C:\Users\gswi\AppData\Local\Programs\PyRx\Bin\PyRx.INI
Loading PyRx from venv condition
K:\Programy\demos\__temp_pyrx_install\venv\Lib\site-packages\wx
PyRxLoader::PyRxLoader_loader Loading, C:\Users\gswi\AppData\Local\Programs\PyRx\Bin\PyRxZ25.0.Zrx
Finished PyRxLoader_loader
PyRx version <1.3.026.20240621> loaded:
Python Interpreter Loaded successfully!

[CEXT-Dan]

Yes, I think that’s correct.
I don’t develop with the package installed, I have a visual studio debug config, copy PyRx25.0.arx, RxLoader25.0.arx, pyrx_onload.py, and relevant debugging files into the same folder, PYRXSTUBPATH is set to my repository.

Originally, I just stuck everything into the .bundle path, but I had to do something different for the clones

I had also thought of installing everything in the same folder and have PackageContents.xml just point to the folder, but I think the user would have to add a trusted path. However, this might be worth revisiting from a python package installation perspective. Install everything into ..\Lib\site-packages, maybe get rid of the .ini file

[gswifort]

Hi, do you have any plans for a new loader in the near future? I'm working on python tools (you can see them here) and I'd be happy if they were tested by a larger group.

[CEXT-Dan]

I want to, it can’t stay the way it is; however, I’m leaving again next Monday until the middle of October. I have task #90 and work on BricsCAD V25 changes. the list is piling up lol

[gswifort]

I understand, I'll try to do a lot of new cool stuff by then. Have a nice trip!

[gswifort]

I’ll continue working on Bim wrappers, albeit with a lower priority

Does this mean you will be working on a new loader in the near future? 😄

[CEXT-Dan]

BricsCAD V25 comes out on 10/23. I have a boatload of support requests logged with Bricsys. I need to work through all the fixes and changes.

[CEXT-Dan]

pyrx_onload.py is loaded from AutoCAD’s findfile search order
https://help.autodesk.com/view/OARX/2023/ENU/?guid=OARX-RefGuide-acedFindFile_ACHAR___AcString__

My reasoning is people might want to have a separate pyrx_onload routines for a particular drawing or project.
I know this contradicts my earlier thought of having multiple files floating around would cause trouble.
I still think it will, but I think the flexibility is cool..