The above is a schematic for how the two CLIs connect and avoid a dependency recursion. What's important to note is that isofit first instantiates itself, loads the ini, then loads the submodules. When loading the submodules, isofit will first check the environment if isoplots is already installed and use that if so, but if not then insert the path provided in the ini into the environment then load it. This insertion enables the downloads module to be the manager of the isoplots installation, avoiding the need for a user to pip install (assuming they have the required packages, but I'll add a check in the download isoplots module for that).

isoplots doesn't load the plotting modules until it is called (ie. get_command()). Therefore, the isofit can load isoplots without loading the submodules, which allows isofit to complete initialization first. Once completed, the isoplot plotting modules may be loaded and import anything from isofit.

After some more development, this is the final architecture. The difference from the first is that the isofit CLI won't attempt to load a presently installed isoplots first before checking if the path to env.plots is valid. Now it always checks if the path is valid and inserts it if so. This enables the -p, --plots override flag to work as expected, in case a user wants to change to a different isoplots installation

Looks good! Clarified a few minor questions with @jammont, so no objections to merge this in. Thanks for conquering the curse, @jammont!