With the public alpha release of the OpenPype v4 server approaching, we have an important announcement about our development focus for the next few months.
We’ve been piling on features into OpenPype quite quickly for a while now, to satisfy popular demand and make OP feature set production-ready for as many studio setups as possible. Now we feel that when it comes to the base feature set, we are able to cover most production scenarios and it is time to shift our focus towards stability, removing technical debt and testability. Following plans should not affect work on individual host workflows or new integrations. We are also continuing work on any and all client requests. With that in mind, here’s a summary of what our short and mid-term plans are.
- Prioritize removing of technical debt and old unused code
- Restructure client application (what we call OpenPype Tray at the moment) to prepare for the switch to v4 server
- Absorb Avalon-Core into OpenPype and stop using it as a dependency
- Prepare client for automatically generated API documentation
- Isolate hosts and modules to enable better modularity and separation of responsibilities
- Prepare tools and their logic for future work on web stack frontends
-
As OpenPype grew from different open source projects and studio setups, it accumulated over time code that is bloating it and making not only testing difficult but also making it hard to orient in it for newcomers (and even for us).
-
We want to clearly separate backend and frontend logic. We realize that some aspects of the pipeline work better if centralized, that’s why we want to move data access strictly to the server-side and to define a clean and robust API to access it (GraphQL and REST). For that, we need to move stuff around in OpenPype Tray so the switch will be easier when v4 is released.
-
We love Avalon-core and it served as the heart of OpenPype very well, but as we grew bigger we’ve found the need to be more flexible and that we need to change the basic behaviour of Avalon-core so much that it will divert radically. For that reason, we are merging its functionality directly into OpenPype so we can make the changes necessary for v4.
-
With the restructuring of OpenPype comes the great advantage of clearly defined and documented API for client and server. Currently, it is very difficult to auto-generate it as it is intermingled with host-specific code, backend and obsolete code. When this is ready, we’ll be able to easily generate nice and human-readable documentation for API, not to mention that it will open for us a way to make proper code tests.
-
We would like to enhance host and module code and dependency isolation that is already present to the level of being able to allow completely different implementations of one host with changes affecting only that specific part of code. Imagine lightweight setups containing only host your studio needs, or the ability to fork one host and replace it with a completely different approach to the pipeline if you need, without touching more code than necessary. Also adding your custom code will be much easier. This will also allow the community to follow changes they are interested in without the clutter of the whole OpenPype universe.
-
As we define a clear API for v4, we’ll be able to provide a more flexible user interface for the artists or developers. We’ll still provide Qt-based tools and UI but at the same time, we’ll be able to add web-based apps with the same or even better functionality that is easier to develop and extend.
Considering the number of contributions we are now receiving, we believe that making sure the core of OpenPype on the server and client-side is really solid, documented and fully testable absolutely essential from a long term perspective and will allow everyone to truly rely on OpenPype for any size of production.
We are also freezing development on new major features until the work on the new client structure is done. This way we should be able to get very close to the final v4 structure while not disrupting the v3 deployments too much.
A detailed breakdown of the steps we need to take is being finalized and will be shared with the community once ready. There will be a special label on Github for all related Pull Requests, so we can keep track of all the changes and make sure anyone currently developing for OpenPype can easily follow and adjust as the work takes place.
Once we are finished, OpenPype will be ready for more robust workflows, and the work will unblock many opened tickets that will be a lot easier to implement with the new structure and with a proper server-side API.
Please feel free to ask any questions and we’ll do our best to clarify everything.