ynput / ynput/ayon-motionbuilder

Remove OpenPype and avalon references

Open
#9 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type: enhancement
Dominant language
Python
Stars
1
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Description

Make AYON and ayon naming as first class citizen for all functionality and metadata naming in repository.

Ideal goal is that openpype, pype and avalon are not mentioned anywhere in codebase. But that probably won't be possible because of backwards compatibility.

Codebase requirements

  • Instances and containers do use AYON_INSTANCE_ID and AYON_CONTAINER_ID instead of AVALON_INSTANCE_ID and AVALON_CONTAINER_ID (constants from ayon-core).
  • If there are metadata stored to scene, we're referring to them as "ayon" metadata and not "openpype", "pype" or "avalon".
  • If there are metadata related to folder, it is not referred to it as "asset" (OpenPype term) - Use correct folder path or folder name based on functionality.
  • If there are metadata related to product, it is not referred to it as "subset" (OpenPype term)
  • If there are metadata related to product type, it is not referred to it as "family", except for publishing (OpenPype term)

And codebase need to change any of that, we must make sure it can be backwards compatible (read older scenes).

Create separate issues if it should be split to multiple PRs, and close the issue if all conditions are met.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by searching the repository for openpype, pype, avalon, asset, subset, and family references, then inspect the AYON constants from ayon-core. Done means the checklist requirements are met across the codebase while older scenes remain readable; split the work into separate issues if multiple pull requests are needed.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
desktop, tooling
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.