the packaging process

[Reissner]

I feel, there is a gap in the documentation.
Maybe my technique is no good but I think the problem i address is real.
I have R2018b.
If i just create a mltbx from the prj file, then a lot of warnings come up.
So i added a function paths in the root folder to be able to paths add the relevant paths.
Reverse engineering seems to indicate that the part of the current paths pointing into the toolbox folder
forms the paths in the mtlbx file.

So for sake of reproducibility, we need (if you accept the other issue on cleanXXX) clean,
then restart MATLAB, then paths add to have reproducible paths.
then open the prj file and package.
Well. This leads me to the suggestion to add paths.m top level also.
Maybe there are other techniques i dont know anything about
but to my knowledge this is a solide concent.

Then comes some gap... you talk about a license file,
but no idea how to include it.
I wrote a separate issue report for this.

To be honest I think we need more:
we need also test if the toolbox is installed already.
To that end: paths rm to remove these paths.
Then double click mltbx to install.
Then finally a check that the toolbox works when installed also.
The paths rm is to ensure that the test dont run on the local copy .
The we need paths test to add paths for tests which are outside toolbox
and then run tests on the installed toolbox..

[michellehirsch]

I don't think we should recommend direct path manipulation.

I'm not sure what the warnings are that you are getting, but the workflow (with a more modern MATLAB) should be something like:

• Use a MATLAB Project to define the path. This includes everything you need for development and for deployment
• Use a Toolbox Packaging task in the project to define the toolbox. Point it to your toolbox folder and define which folders should be on the path (I believe this defaults to anything inside the root folder that's already on your path).

If there's no manual path manipulation, installing an MLTBX should correctly handle the path folders. This should work even if the toolbox is installed.

I agree that testing of the release artifact is tricky, because you need to ensure you've got a "clean" MATLAB. @bpancras, since you are working on the release process, do you have recommendations for this?

[Reissner]

I agree fully: I don't want to set paths explicitly either.
I did only because I don't see any alternatives.

Maybe in your recommendations you must distinguish versions.
There are many legacy systems out there and stably.

If I use old style prj files and open it to package anew, if the paths don't fit, i receive warnings that it will remove certain segments from the path. It is really tricky.

What I do in the meantime is: build clean (self written build.m) cleaning file.
uninstall or deactivate toolbox if installed.
Restart MATLAB to get really rid of the paths (although i have paths clean also).
Then I do paths toolbox adding toolbox paths which would allow already repackaging,
but i wan to test so i call paths tests setting paths for tests also and then build test which tests locally.
Note as I suggested in issue 44, I use a testfolder parallel to toolbox because I do not want to deploy my tests.

If this passes, I do packaging opening the prj file..
Well i always let analyze before pressing the package button.

Then I restart again, install by clicking on xxx.mltbx
and then i do kind of integration test by invoking paths tests and again build test.
Since I did no paths toolbox, really the installed version is tested.
As pointed out above, my tests are not deployed, i keep them local.
Maybe I exaggerate but made very bad experiences already.

I want to point out, that the prj file old style mentions the root folder explicitly.
This is really bad style and hurts privacy very much.
If i pass to someone (s) he knows part of my file system.