Closed dougransom closed 2 years ago
Fixing this would also make life easier since the python modules can be installed in a variety of places, including site-packages, users/appdata/.../site-packages depending if they are admin or not when they install a package.
When natlinkconfig is working, hopefully later a GUI program, you only need to specify for unimacro or vocola the directory of the user defined files, probably in the users documents area (may be in a shared folder, though). The config program defines the correct directories, as needed for the natlink loader.
Pitfall: these directories are in the site-packages area, with a new python version, these can give very confusing errors. As I saw last week, when trying the new installer...
I agree for the part, that the site-packages/vocola2 can be better got from python itself, than hard coded in the natlink.ini file. But... it needs special treatment of vocola2 and unimacro, which is not really wanted in the general design of natlink loading.
The advantage can also be established at least when running the config program.
Again: enabling for exampl vocola2, can be done by setting a flag, or by specifying the user directory for input files. Disabling the other way around.
natlinkstatus gives the wanted information.
[directories] ... vocoladirectory = C:\Program Files (x86)\Python39-32\Lib\site-packages\vocola2 ...
would be better specified as
[modules] vocola2 enabled=True Unimacro enabled=False
Then the loader code could do something like:
import vocola2 as v vocoladirectory=v._path__
except with importlib since the module names are loaded from the ini file at runtime.The existing mechanism could be left as a hook for edge cases.