Is there a MATLAB package manager?

I cannot find any MathWorks endorsed package managers. The user-built solutions I have found do not seem to be popular (PackMan, DepMat, mpm) or regularly maintained. What do people recommend? Is there a reason for the lack of package manager in comparison to pip (python), npm (JavaScript)? How does MathWorks recommend I organise seperate but interdependent code?

[Rik]

There are continuous improvements for the FileExchange, which you could access through the AddOn manager from R2017a. I don't know if there are plans to extend this further and allow submissions to specify versioned dependencies on other submissions.

I vaguely remember seeing such a request, but I can't find it here (nor in the old thread), so feel free to post it there.

[James Bland]

Hi Rik,

Thanks for your repsonse. Im not particular familiar with FileExchange apart from to download the odd matlab script. Is there a particular workflow that you would recommend using, or you use yourself, in packaging up your own code via FileExchange?

[Munin]

I am stabilising MPM in https://github.com/mobeets/mpm/pull/76 you may just use that

[Matt Cooper]

mpm looks promising but here is how to roll your own: install matlab source code (file exchange, github, etc) into a "toolboxes" folder, and manage projects in a "projects" folder. Use setenv() to define these paths in startup.m. Write a function that uses getenv() and dir() to list all subdirectories in these folders and (optionally) save it as a registry. Write a function called activate.m that accepts as input the name of a toolbox or project, reads the registry or uses dir() on the fly, addpath() to 'activate' the toolbox or (for a project) cd into it. Write a function called deactivate.m that does the opposite. Pro tip: put a functionSignatures.json file with activate.m and deactivate.m and populate the 'choices={}' field with the toolbox and project names. Now you have autocomplete, simply type activate <toolboxname> and viola. You can add utilities that integrate with remote source control, like mpm provides, but activate/deactivate will solve 99% of your daily need to navigate from project to project with a clean namespace and a centralized registry of available source code.

[James Bland]

hi Matt,

Thanks for your clear answer, although i still feel that this is code i shouldnt have to reinvent myself

Answer 1

[Sean de Wolski]

Right now there is no package manager like the ones you listed in that everything in MATLAB is tied to the path. Using MATLAB Add-ons with the File Exchange and MATLAB Projects with reference projects are the two best current solutions. You can minimize namespace collisions with namespace packages in MATLAB (note the terminology here does not imply package like in other languages).

[James Bland]

hi sean,

thanks for your answer. If you could point me to any good examples of matlab workflows/ code organisation that would be appreciated!

[Stephen]

@James Bland there is no such thing. Hope this helps

Answer 2

[Rob Campbell]

The fact that this still does not exist is not only real pain but it's arguably holding back the whole MATLAB ecosystem. The lack of a package manager disourages teams of people from building interconnected projects and so makes MATLAB a less attractive platform for serious development.

[James Bland]

yeah i agree

[Maverick]

Did you look at?

https://github.com/mathworks-ref-arch/matlab-dockerfile/blob/main/MPM.md

[Rob Campbell]

That seems to be for Mathworks' Toolboxes and MATLAB as a whole. I am talking about an ecosystem for users and third party code. Something like pip.

[Ashley Trowell]

You are correct. I think the root The problem is that packages themselves are treated as second class within the Matlab environment. The basic practice of adding everything to the path is just asking for namespace collisions. You'll notice the exist function doesn't even support telling you if a package exists on the path. And if you have a complex project and an existing package, and you need to embed that in a different package, you are in for a lot of manual modification which no other programming language requires of you. The result is best practices in avoiding namespace collisions are completely discouraged in matlab. That makes the job of a package manager much more difficult.

A key problem is that files are completely unaware of what namespace they exist in, so you have to fully describe the entire namespace path to call functions that are in the same namespace. This causes the requirement to rewrite every function call when you move code to a new namespace. There's no relative namespace respect.

This is a rather intolerable situation. A utility which might make this less egregious would be a way to automatically refactor code to sit in a new namespace.

[Rob Campbell]

Doesn't importing a package at the top of a function go some way to avoiding having to rename everything?

[Walter Roberson]

@Rob Campbell

Suppose you have package MiddleEarth with subpackage Wizards with function Gandalf . Then you can

import MiddleEarth.Wizards.*

inside a function.

However, there is nothing similar to

import(CurrentPackage, 'Wizards', '*')

so if you change the name of the package from MiddleEarth to Arda then you need to edit every reference in the code to hard-code the new package name.

[Daniel]

Hard agree, @Rob Campbell, but it's unfortunately quite clear that writing even halfway decent software simply isn't in Mathworks DNA. The most recent facepalming example of MATLAB's utter inability to keep up with expected features in every real programming language was when I realized loadenv was introduced in 2023a... I think the most productive thing to do is start working paths to migrate away from MATLAB where possible.

[Jan Kappen]

There is a package manager now, see Organize and Distribute Code Using MATLAB Package Manager - MATLAB & Simulink

[Ashley Trowell]

@Rob Campbell 1 year late, but... You asked if imports solve the namespace issues.

I think Walter's example shows the main reason imports are weak. I can think of two otheres.

A) Walter's example, changing package names and organization is tedious and error prone. Put another way, there are changes which are conceptually simple, eg. nest a package in another package, which may take hours to implement and bug test, because of all the different kinds of labels which may need to be modified, and the fact that an interpreted language won't error until you've followed every path. In a large project, you are almost guaranteed to introduce bugs performing an entirely deterministic operation. (Folks have argued that this is acceptable to prevent people from reorganizing too frequently. No.)

B) Goto Function Definition breaks (At least in previous versions, not sure about 2024.)

Imports broke the functionality of right clicking on a function and saying Go to Definition. You had to decide between the two. I feel that "Goto definition" is critical for languages which are weakly typed and have first class functions. My compromise was to create anonymous functions in a function where I needed an import, because that doesn't break "Goto definition". So inside my function, instead of saying

import signal_tools.visuals.plot_spectrum

I would instead say

plot_spectrum = @signal_tools_visuals.plot_spectrum;

C) Small functions get bloated with imports

Answer 3

[Jan Kappen]

There's a package manager now, see Organize and Distribute Code Using MATLAB Package Manager - MATLAB & Simulink

[Ashley Trowell]

Jan,

Very good news. Thank you for taking the time to share. This looks like an improvement to one of MATLAB's biggest weakness. Give that team a bonus.

Proverbs 25:25 "Like cold water to a weary soul is good news from a distant land."

[Jan Kappen]

@Ashley Trowell I fully agree. And there are livescripts in plain text, i.e. text format now - also an awesome step into the right direction.