New RxLoader

[gswifort]

Based on issue #145

Remove special VENV handling from the main module, and loader, should behave as any other python package. Users will be responsible for what module gets loaded into CAD, in a VENV context.

So we assume that the loader (e.g. RxLoader25.0.arx) and the main module (e.g. PyRx25.0.arx) will be in python packages (...\site-packages\pyrx...) and based on the current environment (whether global or venv) the appropriate main module will be loaded. In my opinion the loader should not be tightly linked to the main module. I assume that the loader can be permanently added to the CAD start list and based on the python environment context the appropriate main module will be loaded. I think that after installing pyrx via pip there should be a command python -m pyrx install-global which will copy the loader to %localappdata%\Programs\PyRx and this loader will be permanently linked to the CAD start list.

[CEXT-Dan]

I would like to remove %localappdata%\Programs\PyRx and put the entire package into ..\site-packages\pyrx
Guessing this will break how loading from a VENV works now. What alternatives are there?

One option is you use CAD profiles for VENV? Does ZwCAD have Command Line Switch?
Like https://help.autodesk.com/view/ACD/2023/ENU/?guid=GUID-8E54B6EC-5B52-4F62-B7FC-0D4E1EDF093A

Maybe a “global” loader could be another project?

[gswifort]

Yes, ZWCAD has command line switches. I don't know if they all do, I tested /b (Script name).

I don't know if putting the loader in a separate project is a good idea, can the main module work without the loader if loaded manually?

The loader can be placed anywhere, %localappdata% is probably the most sensible place - it's not about keeping the whole project there, just the loaders, but the loader can just as well be installed in the site-packages of the global python installation (or even in venv) and the user will decide which loader to attach to the CAD start list.

I think the loader would have to check if the %VIRTUAL_ENV% variable is set

[gswifort]

After some thought, I don't know if removing %localappdata%\Programs\PyRx is a good idea.

I think there are two scenarios to consider:

1. Automation (using CAD as an engine - usually used by people who know what they are doing). In this scenario, CAD can be launched in a specific environment, with a specific master module loaded, etc. This can be done using .scr scripts (/b switch), lisp scripts (run from a .scr script)

2. CAD extensions - In this scenario, the extension developer may want to rely on the main module being loaded and the main module loading its bundle into CAD if it is placed in a specific directory (e.g. %localappdata%\Programs\PyRx\bundle). PyRevit can be used as an example here. Of course, in this scenario, there may be a problem with conflicting dependencies of individual extensions (which should be addressed in a separate thread).

[CEXT-Dan]

If I keep %localappdata%\Programs\PyRx, then I should keep the installer, so it can all be uninstalled, but then it makes no sense to continue with #145. The whole idea was to simplify things by removing directory searches, not add them.

[gswifort]

I think that what I am writing about in scenario number 2 can be implemented entirely in python (I can take care of it). pyrx will remain a package installed by pip, but with an additional option to perform a global installation to %localappdata% (but not via the MSI installer but via python -m pyrx install-global) - thanks to this, the extension developer will be able to check if the global installation has been performed and if not, he will simply perform it from the extension installer. So the loader should probably load the main module located in the same folder. Even if the global loader is added to the start list, running CAD with the /ld switch and specifying a specific loader will cause the specified module to have priority.

[CEXT-Dan]

Ok, I’ll start by making the loader work from anywhere, I.e. ..\site-packages\pyrx, %localappdata%\Programs\PyRx, or in an AutoCAD bundle
I would like to have PIP -uninstall remove %localappdata%\Programs\PyRx if its created with python -m pyrx install-global

[gswifort]

After a short search I'm almost sure that it's not possible to remove a global installation via pip uninstall, you need to define an additional script that the user will have to execute directly.

[CEXT-Dan]

Ouch, yeah, that’s going to be a problem, I think it’s bad practice to leave residual files on a user’s machine from an install.
Regarding PyPi, would be nice, but we don’t have a clear path using PIP yet. I did email PyRx about the name though.

I’ve had a company reach out to me with regards to support with this project, I want to have a clear path to install / uninstall, that could be rolled out company wide.
I need to reach out to the CAD Manager’s group for advice.

[gswifort]

pip install is one procedure, the reverse of which is pip uninstall. I think it's not bad practice to undo python -m pyrx install-global with python -m pyrx uninstall-global.

[CEXT-Dan]

This will also mean there will be a need for update-global? Do you see any probability of versioning issues?

[gswifort]

Yes, but..

It doesn't have to be update-global, the update can be done with the same command (install-global).
This shouldn't cause any problems.