OmniGraph Extension Locations In The Repo
#########################################

* Status: proposed
* Deciders: kpicott, OmniGraph devs
* Date: 2022-08-12

Technical Story: `OM-50040 <https://nvidia-omniverse.atlassian.net/browse/OM-50040>`_

Context and Problem Statement
=============================

All of the OmniGraph extensions were developed directly within Kit. As they grow, and Kit grows, the development
velocity of both the OmniGraph and the larger Kit team are negatively impacted. Kit builds have to wait for all of
the OmniGraph extensions and tests to build, and OmniGraph has to wait for the entire Kit SDK to build.

In addition the Kit team has expressed a desire to move to a thin model where only code necessary to run what they call
"Kit core" should be in the Kit repo, and OmniGraph is not considered part of that.


Considered Options
==================

1. **Status Quo** - we just leave all of the extensions we have inside Kit and continue to develop that way
2. **Single Downstream Replacement** - move all of the extensions downstream of `omni.graph.core` to an extensions repo,
   removing the existing extensions from Kit
3. **Multi Downstream Replacement** - move each of the extensions downstream of `omni.graph.core` to their own
   individual extensions repo, removing the existing extension from Kit
4. **Downstream Copy** - move all of the extensions downstream from `omni.graph.core` to their own repo, bumping their
   major version, but leave the existing extensions in Kit at the previous version and have them be dormant

Decision Outcome
================

**Option 2**: Single Downstream Replacement. Although none of these solutions is perfect this one affords the best
balance of controlling our own destiny and administration overhead. There will be some changes in developer workflow
required to support it, especially in the short term when extensions are transitioned out, and in the medium term
when we have to backport across repos, but in the long run the workflow gains will outweigh the extra efforts.

Moving Extensions
-----------------
It's not practical to move every extension out in a single step so we'll have to move them in small subgroups. The
extension dependency diagram will guide us on the ordering required to move an extension out. Generally speaking an
extension can be moved as soon as nothing in Kit has a direct dependency on it. The
:ref:`extension dependency graph<omnigraph_extension_dependency_graph>` that was extracted from the full list of
dependencies will guide this. Any extension without an incoming arrow can be moved, starting with
`omni.graph.bundle.action`.


Pros and Cons of the Options
============================

Option 1
--------

* **Good** - Workflow is simple, we just build and run Kit and there's no overhead in managing our published versions
* **Bad** - Kit build continues to be slow for all concerned
* **Ugly** - We can't independently version our extensions, Kit becomes increasingly more complex as we add more, our
  tests continue to be subject to instability due to unrelated Kit problems

Option 2
--------

* **Good** - Kit builds and our builds both get way faster, we can version our extension set indpendently of Kit, our
  tests don't rely as much on how the Kit app behaves, just Kit core
* **Bad** - Some developers have to work in multiple repos during the transition, resulting in a clunky workflow for
  testing changes. There's extra overhead in deciding which apps get which versions of our extensions.
* **Ugly** - Backport integration becomes more difficult as previous versions of extensions are not in a related
  repo.

Option 3
--------

* **Good** - We gain full control over extension versioning, builds are even smaller and faster than Option 2, more
  flexible set of Kit SDK versioning gives us a wider variety of cross-version testing
* **Bad** - It becomes more difficult to build tests as typically they will rely on nodes in multiple extensions
* **Ugly** - Multiple repos mean multiple copies of the build to handle, multiple packman packages to wrangle, and the
  overhead reduction we gained by moving out of Kit is lost to administrivia

Option 4
--------

* **Good** - Backward compatibility is easier to maintain as there are full "frozen" copies of the extensions available
  with Kit while we move forward in the separate repo.
* **Bad** - Same as Option 2, plus the Kit builds continue to be slow as they still build our frozen extensions
* **Ugly** - Random test failures will still occur in our code even though we aren't touching it, bugs that arise
  from apps using specific versions of the Kit SDK have to be addressed in the "frozen" copies, and it becomes more
  difficult for apps like Create to choose the correct versions of our extensions.
