Library search for asc_editor and spice_editor can be improved by looking at the simulator path

[hb020]

Right now, I see these search paths:

AscEditor._lib_file_find():
os.path.expanduser("~/AppData/Local/LTspice/lib/sub"),
os.path.expanduser("~/Documents/LtspiceXVII/lib/sub"),
os.path.expanduser("~/AppData/Local/Programs/ADI/LTspice/lib.zip"),

AscEditor._asy_file_find():
os.path.expanduser("~/AppData/Local/LTspice/lib/sym"),
os.path.expanduser("~/Documents/LtspiceXVII/lib/sym"),

SpiceCircuit.get_subcircuit():
os.path.join(os.path.expanduser('~'), "Documents/LTspiceXVII/lib/sub", lib)

asc_to_qsch.convert_asc_to_qsch():
os.path.expanduser("~/AppData/Local/LTspice/lib/sym"),
os.path.expanduser("~/Documents/LtspiceXVII/lib/sym"),

3 issues show up:

1. not all paths are used everywhere
2. this is mainly guess work, while we know the path of the spice executable. The latter could be especially helpful when we have installations with wine, where these specific search paths are guaranteed to point nowhere (requiring the user to use SpiceCircuit.add_library_search_paths() or SpiceEditor.LibSearchPaths.append()), or potentially worse: point to a potentially outdated MacOS version without complaining.
3. I would suggest not using ~/AppData/Local/Programs/ADI/LTspice/lib.zip, as that points to the default installation, not the updated files that are normally in one of the paths mentioned above.

I propose to tweak these searches to base the search on where the simulator really is installed. Will provide a PR.

[hb020]

Just to trace the paths I found:

~/Local Settings/Application Data/LTspice/lib
~/AppData/Local/LTspice/lib
~/Documents/LtspiceXVII/lib

Under wine, ~ should mean the part the simulator's executable path preceding and including /drive_c/ + /users/${USER}/

Under windows or when using the native MacOS simulator, we can just use os.path.expanduser()

[nunobrum]

The paths are not the same everywhere and there is a reason for that. In one case we are looking for symbols, another we are looking for libraries, and another for other .asc files.

[hb020]

Yes, /sub, /sym endings are needed of course. Didn't make that explicit. The main point is that the number of paths to search is not identical everywhere. Working on a POC to automate lib path searches, and to make it easier for the people under wine.

[hb020]

Proposition:

The situation right now

Simulators

• LTspice can use 3 library locations on Windows AFAIK, and a large variety under wine. It also has a 'factory default' set that is typically not updated after initial installation (lib.zip). The base path for the libraries under wine is known to the LTSpice simulator.
• others: no idea in how many locations they can store the libraries. Also no idea if they can run under wine, but if so, the base path for the libraries under wine is known to the simulator, in exactly the same way that applies to the LTspice simulator.

Editors

AscEditor (for LTspice):

• hardcoded paths for the searching of:
  • .lib (/sub): 2 out of the 3 potential paths, + 'factory default', none compatible with wine
  • .asy (/sym): 2 out of the 3 potential paths, none compatible with wine
• custom paths can be added to the above searches via AscEditor.add_library_paths(AscEditor, paths). In addition to the above, the custom paths will also be used for searching of:
  • .asc

QschEditor (for Qspice):

• hardcoded path for the searching of:
  • .lib: 1 path (out of ??), not compatible with wine
  • .qsch: 1 path (out of ??), not compatible with wine
• custom paths can be added to the above searches via QschEditor.lib_paths.extend(paths)

asc_to_qsch (for LTspice to Qspice conversion):

• hardcoded paths for the searching of:
  • .asy (/sym): 2 out of the 3 potential paths, none compatible with wine
• custom paths: via parameters

SpiceCircuit/SpiceEditor (for LTspice, but potentially others):

• hardcoded path:
  • .lib (/sub): 1 path out of the 3 potential paths, not compatible with wine
• custom paths can be added to the above search via .add_library_search_paths(paths) and .LibSearchPaths.append(paths) (same base functionality, although the first is a bit more versatile).

Conclusions

• not all possible Windows paths are hardcoded, and coverage is varying among the functions that use hardcoded paths
• the simulators could in theory help "hardcoding" the correct paths, and cover all platforms
• users of wine must use custom paths now
• the way to set custom paths is not standard among the editors

Propositions

• standardise the way the editors get hardcoded search paths. meaning:
  • get all relevant known paths to the correct places
  • allow seeding the correct paths from the simulators, at editor instantiation (and/or a new function, TBD). This should only be needed for wine. Windows and native MacOS should work correctly by default.
• standardise the way the editors can get custom search paths:
  • a function name and signature should be chosen
  • and mark the others as deprecated
• and adapt the documentation of course

See branch library-searching-69

[nunobrum]

branch library-searching-69 was merged into trunk.
Thanks to @hb020