OpenPype to AYON core addon conversion

Introduction

AYON release v1 is out. Now is time to begin with conversion of OpenPype into AYON core addon, and split existing hosts and remaining modules into their addon repositories.

Current OpenPype repository remains dedicated to OpenPype, while a new repository ayon-core will emerge to house the core addon. That gives us big opportunity to start from scratch.

Plan

Let’s dive into the details of our action plan to smoothly transition OpenPype into the AYON-Core addon.

Initialization of core addon repository - first phase

Steps that will happen before any first PR as initialization of core addon repository. Should be done as fast as possible, and some of the steps will be prepared in advance.

  1. Push develop from OpenPype into the ayon-core repository to keep commit history.
  2. Remove all OpenPype related code from root of repository (igniter, pyproject.toml, tools, ect).
  3. Move content of ./server_addons/openpype/ and ./server_addons/core/ into root to match addon structure, and move openpype content into ./client/.
  4. Prepare create_package.py script.
  5. Remove all code that is only OpenPype related (not needed in AYON). Like tools, mongo code, OP settings backend, all AYON_SERVER_ENABLED conditions, modules that are already separated (some of this may happen later in PRs, based on complexity).
  6. Rename openpype to ayon_core and update all related imports.
  7. Implement backward compatibility for importing ‘ayon_core’ as ‘openpype’.
    • Introduce AddonsManager in ayon_core/addons/ as replacement for ModulesManager with backwards compatibility.

Remove legacy - second phase

  1. Use AYON settings structure → remove settings conversions, and system settings.
  2. Use AYON entity structure → remove entity conversions. e.g. use folder over asset doc.
  3. Use AYON environment variables → replace AVALON_ and OPENPYPE_ environment variables.
  4. Change structure of container and instance in each host (“ayon.instance”, “ayon.container”).
  5. Change keys used during publishing → Use folderPath, folderEntity, addonsManager etc…
  6. Stop using legacy_io.Session
  7. Anatomy can use template categories

Separate addons - third phase

Split hosts and remaining modules into their addon repositories.

Plan conclusion

This transition will require time, testing, and verification, especially during the second phase.

Migration of existing PRs

Due to the extensive changes, migration of existing PRs is not possible. All PRs must be manually converted into new one.

Conflicts

Certain changes may affect existing addons, such as ftrack, kitsu, and shotgrid. Preparation for conflicts, especially related to entity structure and publishing keys, is crucial. Entity structure (using folder instead of asset doc) and keys used during publishing are conflicting every named addon.

Possible solution

We might define a constant USE_AYON_STRUCTURES in ayon_core that would hint addons if they should expect assetDoc or folderEntity. The addons could use it as forward compatibile value.

Day D

Day D determines when initialization of core addon begins. Any PR that should be in ayon core should not be merged in OpenPype repository, unless is CRITICAL for production. When initialization finishes all PRs that should be in OpenPype and ayon-core must be done to both repositories.

This work is starting on 5.2.2024 and we will be updating this topic as work progresses.

4 Likes

This change will cause one very important side effect.

We’ll be closing PRs to OpenPype that are not targeting AYON and kindly ask anyone who is actively contributing to migrate them to the new ayon-core repo, or individual addons once they are up and running.

The aim is a massive PR cleanup of stale work and a nice fresh slate for the upcoming work in AYON. If your PR is closed, please don’t take it personally, we’ll always make a note what is the suggested next step with and hope to see majority of the work make it’s way to AYON.

2 Likes