Does the execution of addpath/rmpath/savepath in one workspace affect other workspaces?
4 Ansichten (letzte 30 Tage)
Ältere Kommentare anzeigen
Does the execution of addpath/rmpath/savepath in one workspace affect other workspaces?
Suppose that I have two instances of MATLAB running on a single laptop. In one of them I may do one of the following.
- addpath(PATH_FOO) or rmpath(PATH_BAR)
- addpath(PATH_FOO) or rmpath(PATH_BAR), and then savepath
- edit pathdef.m (sure, it is not recommended to edit this file manually, but let us be brutal ...), adding PATH_FOO or removing PATH_BAR, and then save pathdef.m
Questions:
- Does anyone of these actions affect the other workspace, sooner or later?
- More generally, what kind of commands that we execute in one workspace can affect the other workspace?
- What if I am running only one instance of MATLAB, but invoke a parfor loop with two loops running in parallel? Does the execution of addpath/rmpath/savepath in one loop affect the other loop, sooner or later? In general, what kind of commands executed in one parallel loop can affect the other loop?
Motivation: imagine that you are developing some package, and you would like to test multiple versions of this package in multipe instances of MATLAB. Each test may do something like addpath, rmpath, savepath, etc. Below is a piece of pseudo code for such a senario.
% MATLAB instance 1
test(package_directory_of_version1);
% MATLAB instance 2
test(package_directory_of_version2);
function test(package_directory)
setup_package(package_dirctory);
test_package;
% The next line uninstalls the package: remove the paths added by
% `setup_package` and delete the compiled MEX files etc.
uninstall_package(package_directory);
end
function test_package
TEST_THE_MEX_FUNCTIONS_PROVIDED_BY_THE_PACKAGE;
% The functions provided by the package are visible here, thanks
% to the `addpath` and `savepath` in `setup_package`.
end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% This is the source code of the package that you are developing.
% It should be called as a blackbox in the tests.
function setup_package(package_dirctory)
mex(FORTRAN_SOURCE_CODE_IN_PACKAGE_DIRECTORY);
addpath(PATH_TO_THE_MEX_FUNCTIONS_PROVIDED_BY_THE_PACKAGE);
savepath; % Make the package available in subsequent MATLAB sessions
end
You want to make sure, of course, the tests do not affect each other. Assume that the tests do not share any data or source code.
Thank you very much for any comments and insights. It would be much appreciated if you could direct me to relevant sections in the official documentation of MATLAB --- I did some searching in the documention, but have not found an answer to my question.
BTW, in case you believe that the test described in the pseudo code is conducted in a wrong/bad manner, I will be very grateful if you could recommend a better way of doing it.
0 Kommentare
Antworten (1)
Steven Lord
am 3 Mär. 2022
IMO the only test that probably should be calling savepath is the test for the savepath function itself. You shouldn't be writing that test: MathWorks has tested that function.
If you need to manipulate the MATLAB path in a test file and you're writing class-based tests I recommend you create and apply a fixture, specifically a matlab.unittest.fixtures.PathFixture. It will handle adding the folder to the MATLAB search path when it is applied and restoring the search path to its previous state when the PathFixture is torn down at the end of the test, regardless of whether the test passes, fails, or errors during execution.
Siehe auch
Kategorien
Mehr zu Startup and Shutdown finden Sie in Help Center und File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!