Mixedrealitytoolkit-unity: [vNext] Consider / investigate removing Unity project structure of MRTK

[davidkline-ms]

Received some customer feedback recently that the MRTK being structured as a loadable Unity project makes it difficult for existing projects to adopt as a GitHub sub-repository.

We should investigate the following options:

• Creating a project based repository that includes the released MRTK branch as a sub-repo
• Is it possible to create a sub-repo that is a branch of the same repository? (ex: releaseMRTKProject containing a link to the releaseMRTK branch)

[SimonDarksideJ]

We'll need more detail to explain what they expect or the problems they see with the current structure / asset.

In either case, this is something we would address in a release, not an issue with how we develop.

[StephenHodgson]

I also don't understand. Is it because of the examples?

[StephenHodgson]

I've used the repo as a submodule without any issue for almost two years.

It depends on how they're setting things up.

[StephenHodgson]

I wrote a detailed blog post about how to import the MRTK as a submodule:

https://www.rageagainstthepixel.com/expert-import-mrtk/

[StephenHodgson]

I'm going to stress the fact that we should not change the structure of the MRTK in any way to accommodate this.

It will slow development time, and will raise the bar for devs looking to contribute.

[StephenHodgson]

As Unity's package manager becomes availible for general use by asset store packages, this will solve a lot of the issues people will face when importing this.

@jwittner is also supporting Nuget packages of the MRTK as well (#1894)

[jwittner]

I hope we avoid encouraging consumption of the MRTK via submodules, and instead get our CI/CD pushing new builds to the Asset Store and NuGet.

My team is using NuGet for our internal Unity libraries and it's wonderful! Checkout NuGet4Unity for NuGet tooling in Unity. It's also available on the Asset Store. =)

[davidkline-ms]

The customers asking for submoduling make changes to the scripts that they then have to manually merge when picking up a new unitypackage release...

Let's monitor this and collect feedback from the community before making any decisions.

[StephenHodgson]

Well, why are they changing third party code changes anyway?

Who ever their devs are that are doing this should be told to stop making changes to third party packages. That's a very bad habit that novice devs pick up. That's why they're having such a hard time. If they need something changed in the toolkit, then they need to open an Issue / PR and get the change submitted into the main project.

[jwittner]

I'm sensitive to their plight as I get many requests from my team about wanting to be able to modify the code from the packages post install. Here's what we're doing, I've bolded the key take aways:

We remind them of the value of sharing their improvements and encourage them to make changes and test scenes in the appropriate library repo - which they have access to - and then make a PR.

• CI/CD saves my bacon here because all the packages push live for our team immediately on merging the PR. This shuts down the argument that moving to this process would slow down development.
• Smaller packages means we can update packages much more frequently.
  
  
  
  • This is something that I believe should be prioritized for the MRTK - development can be split across multiple repos with clear dependencies and then components can be more easily versioned and leveraged independently.
  
  
• SemVer means clear communication on the scope of changes in new packages so expectations are set across all our projects on what updating means.
• Willpower is a finite resource and the temptation to change the code is strong. I prefer to put all code into a .Net project outside of Unity, which builds dlls into a Unity project in a sibling folder. The dlls are then distributed via the NuGet feeds instead of raw source code. This helps lift the burden from our developers and drives better long term behavior.
  
  
  
  • This also lets me use newer C# language features because Unity doesn't see it until it's IL. =)
  
  

That said, the best option I've used for modifying package code is to commit it all to my projects repo, and avoid, if possible, any new 'official' updates. Othwerise it's a git-fu fight to push project changes back on top after updating.

From the asset perspective, e.g. prefabs, I think we need a strong solution around leveraging, with modifications, those that ship in our packages. Right now we either duplicate and copy out of the packages, or write small one off components that expose what we need at the moment, e.g. spawn and configure a prefab. The latter works out much better in relatively short order, but still feels like boilerplate. I'd like a reflective sytem that provided that layer around prefabs in Unity automatically.

[StephenHodgson]

I've also found that duplicating the classes and renaming them helps a lot too, that way both can live in the project together.

[StephenHodgson]

I prefer to put all code into a .Net project outside of Unity, which builds dlls into a Unity project in a sibling folder.

Although I've got to say, working with dlls as components can be difficult and frustrating sometimes.

[davidkline-ms]

First off, thanks for the continued discussion on this.

I find @jwittner's pre-compiled distribution an interesting one for a few reasons:

• It will keep us honest with regards to documentation
  
  
  
  • No fallback to "the code is the doc"
  
  
• Less chance of a customer making a change, installing / pulling a new release and losing his/her work.
• For customers who are not interested in contributing back, source access may be less compelling
  
  
  
  • Source will, as always, be available for download
  
  
• The binary distribution could be signed, providing an additional level of trust

Options are good.

[davidkline-ms]

With regards to the 'why change third party code' question, I am not innocent of making changes to toolkit components in some of my personal projects. When I make changes, it is generally for one or more of the following reasons:

• I am experimenting with a change that may not be appropriate for everyone using the toolkit
  
  
  
  • I don't want to prioritize my needs in the toolkit over the community as a whole
  
  
• The toolkit classes are currently not derived class friendly (vNext will hopefully make this better)
  
  
  
  • Few virtual methods
  
  
  • MRTK classes that directly call a specific class implementation
  
  

When an experiment results in something that i think would benefit more than me, it gets submitted. I'm sure i am not alone in this approach.

[jwittner]

@davidkline-ms Pre-compiled also means a speedier Unity import experience and that the MRTK wouldn't need to recompile every time unrelated code changes. =)

[StephenHodgson]

@jwittner same for custom assembly definitions, which we will be using in vNEXT