add import-like functionality using addpath + mpm

[nkicg6]

Hi I am primarily a python/R/clojure programmer who is now using matlab because a lab I am working in primarily uses it. I have found the global path and a lack of a package manager (like pip) to be a particularly terrible pain point so far. I just came across this package and I really like the ideas here!

I was wondering if you would be interested in a PR for an import package like function for use with mpm . I envision a simple function that is initialized by mpm with the main repository download path and then can temporarily add packages/functions to the path by writing import exampleFunction at the top of the script. I dont think this would be difficult to do and I would be happy to contribute if you think this would be a good idea.

[mobeets]

Cool, yeah sounds interesting! So to make sure I'm understanding, is the idea that the import would be a way to have things in your path just within that script, and then they would be removed when it's done?

[nkicg6]

Yes that is more or less what I am thinking. It would be a wrapper around the built in matlab addpath function https://www.mathworks.com/help/matlab/ref/addpath.html . addpath requires the full path to the file you want to add to your path, but since we know all packages installed with mpm are in the package folder, we could build this into the function.
Ill sketch out an example with some rough code over the weekend for you to look at. The problem is that addpath is active for the whole matlab session, so removing it from the path after the script runs will be hard. At first glance, it would mean requiring the user to add an rmpath https://www.mathworks.com/help/matlab/ref/addpath.html (same idea as import) to the end of the script, but this doesn't seem ideal. I think import is a good place to start (being explicit about script requirements) but isn't the whole solution.

[mobeets]

Hi Nick, thanks again for the suggestion and your pull request. I just realized that this issue here is actually directly related to #26. In #26, instead of putting an "import" at the top of a script, you would write "mpm on imscale" (for example). (And then at the end of the script you could add "mpm off imscale".)

I think I prefer the "mpm on/off" syntax to the "import" approach just because it's more consistent with the way you currently interact with the other mpm features.

I've updated #26 with some details in case it's helpful. If you are interested in taking a crack at this, please let me know!

[nkicg6]

Thanks Jay-
I am looking through that issue now- I'm not quite clear on the proposed usage of mpm on/off. Do you see calling mpm on package1 mpm on package2 ...(or mpm on pkg1 pkg2 ...) for each installed package individually at the top of the script (that's how my example was set up)? I would be happy to work on that as soon as I have some free time this week.
However-- mpm on made me think of pyenv and virtualenvwrapper for python, it sounds like mpm on environment-name (similar to the idea proposed in #41 ) may be a great way to manage actual virtual environments for a script in a manner similar to pyenv.
I'd envision it like so:
An initial call to
mpm create environment-name could make a new environment-name_pathlist.mat which could be edited with a function mpm add environment-name pkg1 pkg2 pkg3 (pkg* from installed packages). mpm add would just append the full paths to that new environment mat file. Then, calling mpm on environment-name at the top of a script could add all of the files in the environment-name_pathlist.mat to the path, and calling mpm off environment-name at the bottom (in in the console) would reverse. This would minimize the typing that would be required for both the import idea and wouldn't require messing with boolean flags in the metadata like in #26
Let me know which version you like (or if neither is what you are thinking of)- I'd be happy to contribute to this project!

[mobeets]

Right, yeah good point, the idea in #41 of environments is also worth implementing. I will make a separate issue for implementing #41. (I like the syntax of initializing an environment with mpm init [envname] rather than mpm on, since mpm init is already a default environment in a sense.)

I was just looking back at #20, and the initial motivation for the mpm on/off idea was exactly the same as this issue, which is to add an import-like function (for mpm on), or in cases where you need to rmpath to a package (mpm off). So I'll close this issue here, and leave open #26. (And to answer your question, yes, I imagine using it like mpm on matlab2tikz; mpm on export_fig etc.)

You're welcome to work on whichever one sounds more interesting!

[mobeets]

Also, for #26, I don't think the boolean is_on is actually needed at all. so mpm on and mpm off are basically just making calls to addpath and rmpath, so should be pretty straightforward to implement.

[mobeets]

Hey, turns out the code in pull request #41 was actually already good to go, so I went ahead and incorporated it with the new code. So now an environment is called a collection--see #55.