What is the best way to use MRTK3 with some custom changes?

[edgar-rodrigo-santos]

Hi.

When we used MRTK2 we felt the need to make some changes to the MRTK2 code (usually very simple changes to allow extending it).
The MRTK2 releases page had unity packages that could be imported into the project, so we used to do that and kept that code under our version control. Whenever we needed to update, we did the same while reviewing our changes (that were documented internally).
We understand this is far from a perfect solution, but it served our needs at the time since it could be done quickly.

Now that we are shifting our attention to MRTK3, we have a similar scenario, and we're having some trouble coming up with a process (even if it's not perfect) that is similar to what we did with MRTK2.

First, as a baseline, we just used the Mixed Reality Feature Tool to install the necessary packages and get a simple demo working in Hololens 2.

Then, as an example of a potential need we will have in the future, I wanted to make some changes to the "MRTK UX Components" code. I thought I could get away with uninstalling that particular package and just manually adding the code (from the releases page) of that component directly into the project. Unfortunately, that code complains that it doesn't know about the namespaces of its dependencies (which are still in the project as packages that were installed with the mixed reality feature tool). The assembly definition also looks OK, and its dependencies point to the correct assembly definitions of the packages. I am very confused about this not working correctly.

Next, I tried an approach similar to what we did with MRTK2: adding all the MRTK3 packages code directly to our project.
It doesn't work out either. At first, it asked for one extra dependency (which was not an issue when it was imported via package manager, so it is strange), and then it looks like some pre-processor constants are not defined properly (even though I see in the assembly definitions that the "Version defines" sections have the same data as they did when the code was imported via package manager).

My question is: What am I missing here?
On the one hand, I need to understand why this process is not working for me (why is there a big difference between importing via package manager and just putting the release page code directly in the project).
On the other hand, I would also like to ask you what would be the ideal way to use MRTK3 with some custom changes. Is there a proper way to do this? We thought of forking the project and using git-submodules, but that also looks unpractical, as it looks like what ends up in Unity are artifacts of the build process and not this repo directly (please correct me if I'm wrong).

I'm sorry for the long question, and I thank you for your patience in reading this.
I imagine this scenario might not be so uncommon, so hopefully this can also be of help to others :)

[camnewnham]

In response to your title question, you can fork the project and edit as you see fit. Then, reference your own fork in your Unity package manifest.json. See here for the syntax: https://docs.unity3d.com/Manual/upm-git.html

For MRTK3, this can be done by specifying the paths to the packages, for example:

{
  "dependencies": {
    ...
    "org.mixedrealitytoolkit.spatialmanipulation": "https://github.com/MixedRealityToolkit/MixedRealityToolkit-Unity.git?path=org.mixedrealitytoolkit.spatialmanipulation#v3.0.0",
    "org.mixedrealitytoolkit.input": "https://github.com/camnewnham/MixedRealityToolkit-Unity.git?path=org.mixedrealitytoolkit.input#5567a6a01939a8da2e94df8adf31f9cec4c53fbd"
    ...
  }
}

In this case, the spatial manipulation package is using this repo as it was when it was tagged v3.0.0. I'm using a fork of MRTK with changes to the input package to hotfix a bug until it's merged, so I've tagged the specific commit and referenced my fork in the package manifest.

Note that not all features in the MR feature tool are available by this method, but most are (i.e. Graphics Tools)

The side benefit of using git references instead of the MRTK feature tool is that if you use a blank slate CI you won't use a ton of git LFS bandwidth.

[edgar-rodrigo-santos]

In response to your title question, you can fork the project and edit as you see fit. Then, reference your own fork in your Unity package manifest.json. See here for the syntax: https://docs.unity3d.com/Manual/upm-git.html

For MRTK3, this can be done by specifying the paths to the packages, for example:

{
  "dependencies": {
    ...
    "org.mixedrealitytoolkit.spatialmanipulation": "https://github.com/MixedRealityToolkit/MixedRealityToolkit-Unity.git?path=org.mixedrealitytoolkit.spatialmanipulation#v3.0.0",
    "org.mixedrealitytoolkit.input": "https://github.com/camnewnham/MixedRealityToolkit-Unity.git?path=org.mixedrealitytoolkit.input#5567a6a01939a8da2e94df8adf31f9cec4c53fbd"
    ...
  }
}

In this case, the spatial manipulation package is using this repo as it was when it was tagged v3.0.0. I'm using a fork of MRTK with changes to the input package to hotfix a bug until it's merged, so I've tagged the specific commit and referenced my fork in the package manifest.

Note that not all features in the MR feature tool are available by this method, but most are (i.e. Graphics Tools)

The side benefit of using git references instead of the MRTK feature tool is that if you use a blank slate CI you won't use a ton of git LFS bandwidth.

That seems to work out pretty well. Thank you.

[AMollis]

Moved this to the discussion board, since it is not tracking an actual bug or feature request