MATLAB Path Management

[jared321]

For a project that is using MATLAB POUNDERS presently, my callpounders.m sets the current working directory (CWD) to the location in which needed configuration files are stored and where I want results to be written. This is completely unrelated to where IBCDFO is installed.

However, this doesn't presently work because of the relative path in https://github.com/POptUS/IBCDFO/blob/0b6d01771a6f1c2e0e2dd209c23d4af14a6de54e/pounders/m/pounders.m#L7-L9

which I believe looks for general_h_funs with respect to the CWD.

@jmlarson1 @mmenickelly @wildsm Can we assume that if someone is calling a specific pounders.m, then they should be using the general_h_funs in the same clone? If so, then how about using

[here_path, ~, ~] = fileparts(mfilename('fullpath'));
addpath(fullfile(here_path, 'general_h_funs'));

[jared321]

It looks like users (or perhaps the person who writes something like callpounders) are expected to add the location of the correct minq to MATLAB's path. Based on your response to the above and the above technique for adding to the path, couldn't POUNDERS automatically add the correct minq to the path based on the final value of spsolver?

[jared321]

Some potentially useful info regarding addpath:

• If you use addpath within a local function, the path change persists after program control returns from the function. That is, the scope of the path change is global.
• While I've seen no explicit mention of the supported behavior, you can add the same folder to the path multiple times and it is added effectively only once. If you add the same folder twice but with another added in between (e.g., "..", "../..", ".."), then the duplicated folder is just added once with the last call setting the folder higher up in the search stack (e.g., ".." will be searched before "../.."), which makes logical sense.

In light of this, is it acceptable for a tool like POUNDERS to blindly add general_h_funs or minq5 to the path automatically without seeing if they are already in the path or restoring the PATH upon termination? Is there a reasonable use case where someone might manipulate the PATH so that an alternate version of external dependencies are found?

[jared321]

It looks like manifold_sampling_primal uses POUNDERS's checkinputss function, which necessitates adding pounders/m to the path.

Naively, I would believe that if I want to use one method, I shouldn't add another method to the MATLAB path unless there is an obvious dependence such as between POUNDERS and MINQ.

@jmlarson1 @mmenickelly Would a better solution be to add a folder such as common/m to IBCDFO and locate checkinputss there? Copy or symlink checkinputss into manifold_sampling/m?

[jared321]

As part of working Issue #145, I have come across

• a MATLAB feature called Projects, which appear to be analogous to virtual environments. In particular, you can install setup/teardown scripts that can setup/teardown the environment including the path.
• a MATLAB feature called Toolboxes which community developers can setup. They appear to be analogous to Python packages.

These might ease path management and overcome some of the aforementioned technical difficulties.

Consensus is that for now we assume that MATLAB users are happy to work from a clone of the repo with the need for them to alter the path. In particular, there is no need to offer the MATLAB code as a potentially simpler, cleaner toolbox through FileExchange. The possibility of methods such as pounders.m silently altering their path at the global level as a side effect is not particularly troubling for a such a workflow.