Move Samples out of Assets

[jbienzms]

Should the HoloToolkit-Examples folder really be under Assets? I used to tell everyone that they need to include everything from the Assets folder and below to make sure the got the RSPs (a common mistake). But now that would include all of the samples too.

I feel the samples should exist off the root somewhere, like the Sharing stuff does in:

External/HoloToolkit/Sharing

But I could be missing something. Any thoughts?

[DanHolbert]

I think the thought is that (A) when you get HoloToolkit, you’re going to want some reference code on how to use it, and this makes it that much simpler, and (B) if you make any changes, you’re less likely to break something if you have the canonical examples as part of your project. It shouldn’t be enough data worry about disk bloat.

[studio216]

When you use source control, I generally include everything in the asset
folder. It would be great if we did not have to make an exclusion for the
samples directories as well. Also Unity likes to rebuild the cacheing and
meta files under certain conditions.

I vote for moving them outside the asset directory and allowing the dev the
option of bringing them in as needed.

On Mon, Aug 15, 2016 at 2:38 PM, Dan Holbert notifications@github.com
wrote:

I think the thought is that (A) when you get HoloToolkit, you’re going to
want some reference code on how to use it, and this makes it that much
simpler, and (B) if you make any changes, you’re less likely to break
something if you have the canonical examples as part of your project. It
shouldn’t be enough data worry about disk bloat.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#174 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJAJpiMfyRC_axRsWaFLIunTgK74_Af6ks5qgNxJgaJpZM4JkyEb
.

[jwittner]

There are lots of pros and cons for both sides on this, but we felt that given a tight focus (examples should make heavy use of the HTK and should not be complex) it was unlikely that the examples section would be much of a burden on developers, but could be of great help for learning the HTK. Moving them out also means the overhead of multiple Unity projects. Moving them to another repo was a non-starter due to the overhead of managing multiple public GitHub repos.

There's also a long term vision that most developers would be embedding the HTK into their projects via a published package on the Unity Asset Store. In that case it's really easy to exclude them by unchecking the box for the Examples folder and including it falls in line with what we see in many Unity packages available from the store.

[NeerajW]

@jwittner articulated the thinking amazingly well. Hope that answers your question.

HoloToolkit-Examples is under assets because:

1. Teachability: It's makes it easy to look at examples which are not unit tests. Teaches you how to use the HoloToolkit.
2. Maintainability: Developers don't need to create a separate fork or branch for hosting their examples. Contributors don't need to enlist in other repositories. They can do everything in the same clone. Moderators don't need to moderate different repositories. Examples get better maintained if they are along side the core functionality.
3. Importability: You can easily delete the entire folder if you don't wish to make use of them in your app. With unity package imports this is made simpler. Yet to be on the unity asset store.

We do acknowledge, the repo size may increase but disk storage space has become a lot cheaper over the years :)

[jbienzms]

I understand all of these points. I guess point number 3 is the one most impacted by location.

If the samples were located at

HoloToolkit-Unity/Examples

instead of

HoloToolkit-Unity/Assets/HoloToolkit-Examples

Teachability would be similar in that being at the root is easy to find. But I agree that they would not compile at the root and would have to be moved to Assets anyway if you wanted to actually run them.

Developers would still not need to create a separate fork or branch because the examples would still be in the same repository.

But Importability has the biggest impact because you couldn't just grab the Assets folder and convert it to a Unity package. You'd have to manually include a folder from another location and that would make packaging it up more complex.

I understand the logic behind this organization and I can see how if it showed up as a checkbox in a Unity Package I could easily just uncheck the box.

I personally do not create a separate copy of the toolkit for every project. I use linking to share one copy of the toolkit across projects. So I wasn't fond of the samples causing all my projects to load longer. But as Neeraj point out, I can just as easily delete the samples folder if I don't want them.

Thank you everyone for sharing your thoughts. I'm fine with closing this issue.